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ABSTRACT 

This  thesis  describes  the  potential  use  of  a  general-purpose  controller  autonomously 
to  measure  acoustic  vibration  in  the  Space  Shuttle  Cargo  Bay  during  launch.  The  ex- 
perimental package  will  be  housed  in  a  Shuttle  Get  Away  Special  (GAS)  canister. 

We  have  implemented  the  control  functions  with  software  written  largely  in  the  C 
programming  language.  We  use  an  IBM  MS  DOS  computer  and  C  cross-compiler  to 
generate  Z-SO  assembly  language  code,  assemble  and  link  this  code,  and  then  transfer  it 
to  EPROM  for  use  in  the  experiment's  controller.  The  software  is  written  in  a  modular 
fashion  to  permit  adapting  it  easily  to  other  applications.  The  software  combines  the 
experimental  control  functions  with  a  menu-driven,  diagnostic  subsystem  to  ensure  that 
the  software  will  operate  in  practice  as  it  does  in  theory  and  under  test. 

The  experiment  uses  many  peripheral  devices  controlled  by  the  software  described 
in  this  thesis.  These  devices  include:  a  solid-state  data  recorder,  a  bubble  memory 
storage  module,  a  real-time  clock,  an  RS-232C  serial  interface,  a  power  control  subsys- 
tem, a  matched  filter  subsystem  to  detect  activation  of  the  Space  Shuttle's  auxiliary 
power  units  five  minutes  prior  to  launch,  a  launch  detection  subsystem  based  on 
vibrational  and  barometric  sensors,  analog-to-digital  converters,  and  a  heater  subsystem. 
The  matched  filter  design  is  discussed  in  detail  in  this  thesis,  and  the  results  o^  a  com- 
puter simulation  of  the  performance  of  its  most  critical  sub-circuit  are  presented. 
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GLOSSARY 

Analog-to-digital  (A/D)  Converter:  Analog  signals  are  signals  whose  levels  var\-  con- 
tinuously as  a  function  of  time.  Digital  signals  are  signals  which  take  on  discrete 
(quantized)  values,  and  these  values  remain  constant  for  some  given  period  of  time, 
at  which  time  the  level  is  updated.  An  analog-to-digital  converter  samples  a  contin- 
uous input  signal,  decides  which  of  a  finite  set  of  discrete  values  is  the  best  one  to  de- 
scribe the  input  signal,  and  outputs  that  discrete  value.  A  regular  clock  is  used  to 
cause  the  input  to  be  sampled  again  on  a  repetitive  basis,  and  the  output  likewise  is 
updated  at  the  same  rate.  .A  digital  computer  cannot  deal  with  continuous  signal  lev- 
els, so  A  D  converters  are  routinely  used  to  let  such  computers  read  signal  levels  in  the 
form  they  can  handle,  as  digital  values. 

AiL\iliar>-  Po>\er  Unit  (APLO:  The  .APUs  are  jet-turbine-powered  engines  used  during 
both  launch  and  recover}-  to  operate  the  control  surfaces  of  the  space  shuttle.  Because 
they  have  a  limited  amount  of  fuel,  the  mission  will  be  scrubbed  if  they  operate  for 
more  than  seven  minutes  before  launch.  The  Vibro-acoustic  Experiment  attempts  to 
detect  them.    If  it  is  successful  in  doing  so,  it  can  anticipate  launch. 

ASCII:  American  Standard  Code  for  Information  Interchange.  This  is  a  seven-bit 
data  code  used  in  many  digital  systems  to  represent  alphabetic  and  numeric  characters, 
punctuation  marks  and  a  number  of  non-printing  characters  commonly  used  to  pass 
information  from  one  device  to  another.  Since  most  digital  systems  are  based  on 
eigiit-b:t  b\tcs.  one  bit.  the  high-order  one.  is  unused  in  the  ASCII  scheme.  It  is  not 
unconimon  for  manufacturers  to  appropriate  the  extra  bit  for  their  own  purposes. 

B.AUD:  The  baud  rate  is  the  number  of  symbols  transmitted  in  one  second.  In  many 
computer  systems,  one  symbol  can  represent  one  bit  (zero  or  onei  and  so  the  baud  rate 
and  the  bit  rate  are  equal. 

BCD:  Binary  Coded  Decimal.  In  this  format,  two  four-bit  codes  are  stored  in  a  single 
eight-bit  byte.  Each  of  these  four-bit  codes  can  take  on  any  of  ten  values  from  0x0 
through  0x9.  Values  from  Oxa  through  Oxf  are  forbidden.  The  interpretation  of  these 
four-bit  codes  is  that  they  represent  the  decimal  digits  from  0  through  9.  Thus,  a  single 
eight-bit  byte  can  represent  decimal  numbers  from  0  through  99.  This  iormat  is  the 
only  one  used  by  the  National  Semiconductor  MM58167A  real  time  clock. 

Bubble  Memor>-:  This  is  a  form  of  integrated  circuit  memor\-  which  uses  magnetic 
domains  for  storing  information.  These  domains  look  like  bubbles  when  viewed  under 
a  microscope,  hence  the  name.  Applying  magnetic  fields  to  the  bubbles  causes  them 
to  move  about,  permitting  the  information  they  represent  to  be  stored  and  retrieved. 
From  the  standpoint  of  a  user,  they  generally  have  two  chief  characteristics: 

1.  The  data  are  stored  in  a  combination  of  random  and  sequential  methods.  Thus 
groups  of  data  can  be  accessed  randomly,  but  the  elements  of  the  group  must  be 
accessed  sequentially.  This  is  analogous  to  the  way  a  disk  storage  device  oper- 
ates. It  accesses  tracks  directly,  by  moving  its  read-write  head  radially  over  the 
disk's  surface  to  one  of  a  set  of  concentric  circles,  called  tracks.  Once  the  head 
is  positioned  over  the  desired  track,  data  is  sequentially  read  from  or  written  to 


2.  The  data  they  contain  are  non-volatile.  Removing  power  from  them  does  not 
destroy  their  contents,  provided  this  is  done  in  a  controlled  manner.  This  is  in 
contrast  to  the  destruction  of  data  in  typical  integrated  circuit  memories  when 
power  is  removed  from  them.  Those  memories  are  non-volatile  only  if  a  battery- 
backup  is  available.  The  Intel  bubble  memory  we  are  using  will  lose  data  if  the 
temperature  wanders  outside  the  range  [  —  20,  +  75]°C  [Ref.  1:  Chapter  1,  p. 3). 

Digital-to-analog  (D/A)  converters:  See  the  earlier  discussion  of"  analog-to-digital  con- 
verters for  some  background  on  the  difference  between  analog  and  digital  signals.  The 
purpose  of  the  digital-to-analog  converter  is  to  convert  a  digital  signal  to  a  smoothly 
varying  continuous  signal.  Since  the  digital  signal  actually  varies  in  jumps,  it  is  not 
smooth  to  begin  with.  D  A  converters  use  low-pass  filters  to  eliminate  the  high- 
frequency  components  represented  by  the  sudden  jumps  of  a  digital  signal. 

Dynamic:  In  the  C  programming  language,  most  variables  are  dynamic.  This  means 
that  they  are  created  when  a  C  function  commences  executing  and  are  destroyed  when 

that  function  completes  executing.  This  is  in  contrast  to  the  way  static  (q.v.)  variables 
work. 

EEPROM:  Electrically  erasable,  programmable  ROM  (q.v.).  The  contents  of 
EEPROMs  are  not  as  easily  modified  as  arc  the  contents  of  R.\\Is.  but  they  are 
non- volatile  (they  don't  lose  their  contents  when  power  is  remo\ed.)  The  contents  of 
these  memories  can  be  erased  electrically,  but  generally  at  a  much  slower  rate  than 
that  at  which  they  can  be  read. 

EPROM:  Erasable,  programmable  ROM  (q.v.).  EPROMs  can  be  erased  for  re-use 
if  they  are  exposed  to  ultraviolet  light  for  several  minutes.  It  is  usual  to  remove  the 
integrated  circuit  from  the  circuit  board  to  do  this.  EPROMs  have  a  limited  lifetime 
due  to  wear  on  the  pins  (unless  zero-insertion-force  sockets  are  used)  and  because  their 
ability  to  be  erased  diminishes  with  age. 

E.xecutable  Program  Module:  The  output  of  the  link  process  (^.i.)  is  a  single  file  of 
machine  code  instructions.  When  placed  in  the  computer's  memory  at  the  correct  lo- 
cations (specified  in  advance),  these  instructions  permit  the  computer  to  execute  a 
program. 

FIFO:  First-in,  first-out.  This  term  refers  to  a  common  data  structure.  One  place 
this  data  structure  is  used  is  in  the  butler  on  the  bubble  memory  controller.  That 
bulTer  serve^;  as  an  intermediate  storage  area  between  the  bubble  memory  and  the  user. 
For  example,  when  data  are  being  read  from  the  bubble  memon.-  by  the  user,  they  are 
retrieved  from  the  bubble  memory  by  the  bubble  memory  controller  and  placed  in  the 
FIFO  buffer.  Concurrently,  data  are  being  removed  from  the  bufler  and  sent  to  the 
user.  The  first  characters  of  information  to  arrive  in  the  buffer  are  the  first  to  leave, 
hence  the  first  in  are  the  first  out. 

Firmware:  This  term  describes  the  computer  programs  which  are  stored  in  non- 
volatile memory,  such  as  ROM  (^.v.) 

Handshaking:  When  two  devices  communicate,  they  employ  a  protocol  which  speci- 
fies which  device  does  what,  when.   This  protocol  is  referred  to  as  "handshaking". 

Hexadecimal:  Numbers  to  the  base  16.  It  is  customary  to  use  the  usual  digits  (0-9) 
as  well  as  the  letters  'A'  (or  'a')  through  'F'  (or  T),  for  the  16  distinct  symbols  required 
in  this  system.    The  C  programming  language  by  convention  uses  the  prefix  'OX'  (or 


•Ox')  to  make  it  clear  that  the  appended  characters  represent  a  hexadecimal  quantity. 
For  example. 

2a,6  =  Ox2a  =  2^^  x  16^  +  a,^  x  16°  =  2  x  16*  +  10  x  16°  =  42. 

Input/Output  space:  The  Z-SO  and  the  essentially  similar  NSC800  provide  a  separate 
set  of  addresses  for  input  and  output  devices.  Certain  instructions  are  reserved  for 
these  addresses,  which  can  run  from  OxOO  through  OxlT.  They  do  not  interfere  with  the 
corresponding  memory  address  space  {q.v.) 

I/O:    Input  or  output. 

I/O  Space:    See  Input/Output  Space. 

Latch  up:  A  comparator  will  ordinarily  produce  a  high  voltage  when  the  non- 
inverting  input  receives  a  higher  voltage  than  that  present  on  the  inverting  input. 
Similarly,  it  will  ordinarily  produce  a  low  voltage  when  the  non-mverting  input  re- 
ceives a  lower  voltage  than  that  present  on  the  inverting  input.  Some  comparators 
are  susceptible  to  the  phenomenon  called  "latch  up".  This  entails  a  failure  of  the 
comparator  to  change  its  output  accordmg  to  the  usual  rules.  Instead,  the  output 
signal  will  remain  stuck  at  one  value  without  regard  to  changes  at  the  input.  This 
feature  is  highly  undesirable,  as  it  means  that  the  comparator  is  no  longer  performing 
as  it  should. 

Libran':  The  output  of  the  compilation  or  assembly  steps  is  an  object  module.  Se- 
veral of  these  can  be  stored  in  a  library  for  convenience.  During  the  link  process,  the 
linker  can  look  in  the  modules  stored"  in  the  library  for  definitions  of  objects  whose 
names  it  does  not  recognize.  The  alternative  to  putting  modules  m  a  library  is  to 
specify  them  individually  to  the  linker,  which  is  somewhat  less  convenient. 

Linker:  The  linker  is  responsible  for  combining  the  object  modules  which  comprise 
a  complete  program,  and  placing  them  in  suitable  memor>-  locations.  Object  modules 
may  include  references  to  other  modules  or  identifiers  defined  within  other  modules. 
These  references  must  ultimately  be  resolved  to  memory  addresses  within  the  com- 
puter which  will  run  the  executable  program.  It  is  the  job  of  the  linker  to  perform  this 
address  resolution.  To  link  a  program  is  to  request  the  linker  to  construct  an  execut- 
able program,  and  resolve  all  unknown  addresses.  The  object  modules  may  be  ob- 
tained by  the  linker  from  either  of  two  sources:  from  a  library  or  from  individual  files 
containing  only  one  module  each.  The  output  from  the  linker  is  a  single  lile  contain- 
ing an  executable  program  module  (c/.v.) 

Memon-  address  space:  The  Z-80  and  the  essentially  similar  NSC800  permit  address- 
ing memor\-  with  addresses  in  the  range  OxOOUO  through  OxfilT.  Most  instructions 
which  use  addresses,  including  stack  instructions  which  do  not  explicitly  address 
memor}'.  use  this  space.  There  is  another  space  of  addresses  called  the  input  output 
space  iq-v.) 

Module:  In  the  C  programming  language,  many  functions  may  be  grouped  together 
in  a  single  file  of  source  code.  These  are  considered  to  comprise  a  single  module,  for 
they  are  compiled  as  a  unit  and  the  resultant  object  code  is  stored  in  a  single  file,  an 
object  module  ^q.wj.  Similar  remarks  hold  when  the  source  code  consists  of  assembly 
language  instructions,  rather  than  instructions  in  the  C  programming  language.  In- 
deed, this  concept  is  applicable  irrespective  of  the  programming  language  used  to  cre- 
ate the  executable  program.  There  are  several  advantages  to  building  modules  in  this 
fashion.    Chief  among  them  is  the  separation  of  sections  of  a  program  according  to 


their  functional  characteristics.  This  permits  testing  one  module  independent  of  test- 
ing any  other  module.  It  also  facilitates  the  use  of  fully  debugged  programs  for  other 
applications  at  a  later  date. 

Modulo:  Consider  a  number  x  and  another  number  m.  called  a  modulus.  The  number 
X  taken  modulo  m  is  written  .v  mod  m  and  it  is  defined  to  be  the  least  positive  number 
n  such  that  x  =  k  x  m  +  n  for  some  integer  k.  As  an  example,  5  mod  6  =  5  because 
0x6  +  5  =  5.  Similarly,  9  mod  6  =  3  because  9=1x6+3,  and  —2  mod  6  =  4  since 
— 2  =  —  1  X  6  +  4.  Although  we  can  also  write  — 2  =  — 2  x  6  +  10,  —2  mod  6  t^  10  be- 
cause 10  is  not  the  least  positive  number  which  can  be  found  to  satisfy  the  equation. 

Nibble:  A  nibble  is  a  half  byte.  This  is  a  typical  example  of  humor  in  the  computer 
business. 

NSC810A:  An  integrated  circuit  from  National  Semiconductor  which  includes  two 
eight-bit  ports,  one  six-bit  port,  128  eight-bit  words  of  R.A.VI  (q.v.)  and  two  16-bit  bi- 
nary timers. 

Object  Module:  An  almost-executable  computer  program.  The  reason  it  is  not  fully 
executable  is  that  not  all  addresses  within  it  have  been  resohed  yet.  nor  has  the  linker 
established  what  addresses  should  be  assigned  to  relocatable  programs.  Assemblers 
and  compilers  produce  object  modules.  Linkers  convert  them  into  executable  form 
by  resolving  the  unresolved  addresses  and  assigning  all  relocatable  code  to  its  final 
location. 

Parametric  Registers:  The  Intel  BPK  5V75A  Four-Megabit  Bubble  Memor\'  includes 
fi\'e  parametric  registers  which  must  be  loaded  prior  to  attempting  to  perform  input 
from  or  output  to  the  bubble  memon.'.  Two  of  the  five  comprise  the  block  length 
register,  which  defines  both  the  number  of  bytes  contained  in  a  page  of  bubble  mem- 
ory {e.g.,  64),  and  the  number  of  pages  to  be  transferred  from  bubble  memory-  to  the 
bubble  memory  port  or  vice  versa  at  a  time.  Two  more  specify  at  which  of  the  8.192 
pages  in  the  bubble  memory  to  start  the  transfer  of  data.  The  last,  the  '"enable"  reg- 
ister, primarily  defines  whether  operation  is  to  be  interrupt-driven  or  not. 

Project  G-3I3:  This  is  the  designation  of  the  NASA  project  comprising  the  Vibro- 
acoustic  Experiment. 

PROM:  Progranimable  ROM  (^.v.)  These  ROMs  can  be  written  to  once  by  the  user, 
but  once  UTitten.  their  contents  can  never  be  modified. 

Quotation  Marks:  In  C,  double  quotation  marks  ("  ")  are  used  to  enclose  character 
strings.  Internally,  the  C  compiler  always  places  an  ASCII  NUL  character  (its 
hexadecimal  representation  is  0x00)  at  the  end  of  a  string.  Single  quotation  marks 
('  ')  are  used  to  enclose  a  single  character.  Internally,  the  C  compiler  does  not  append 
an  ASCII  0x00  to  a  single  character. 

RAM:  Random  access  memor\'.  This  refers  primarily  to  memory  which  can  be  writ- 
ten to  and  read  from  repeatedly.  It  commonly  is  volatile,  i.e.,  its  contents  are  de- 
stroyed when  power  is  removed. 

ROM:    Read-only  memory.    This  term  is  a  bit  of  a  misnomer.    Obviously  a  memory 
which  can  never  be  written  to  would  be  of  little  value.    Generally,  it  is  much  more 
difiicult  to  modify  the  contents  of  a  ROM  than  it  is  to  modify  the  contents  of  a  R.AM. 
ROMs  come  in  several  varieties: 


1.  A  mask-programmed   ROM   receives  its  data  at  the  factory  according  to  a 
customer's  specification  when  it  is  manufactured. 

2.  A  PROM  (^.v.)  IS  programmed  once  by  the  user. 

3.  .An  EPROM  [q.v.)  can  be  programmed  repeatedly,  but  must  be  erased  by  ultra- 
violet light  between  uses. 

4.  .An  EEPROM  (^.v.)  also  can  be  programmed  repeatedly,  but  it  can  be  erased 
electrically. 

RS-232C  Serial  Interface:  This  interface  is  also  known  as  the  EI  A  siamiard  interface 
It  was  developed  in  1909  by  the  Electronic  Industries  Association  in  conjunction  with 
the  Bell  system,  as  well  as  independent  manufacturers  of  computers  and  modems. 
Data  are  transmitted  serially  using  two  voltage  levels.  +  \\  represents  a  binarv-  0: 
-  V,  represents  a  binar\-  1. 

The  voltage  \\  can  he  within  the  range  [3.25]V.  \Miile  the  RS-232C  defines  the 
electrical  characteristics  of  the  interface,  the  functional  description  of  the  interchange 
circuits,  and  lists  standard  apphcations.  it  is  silent  on  the  subject  of  physical  connec- 
tors. Usuallv,  however.  DB-25  connectors  havins  25  pins  are  used.  The  tables  in 
APPENDIX  I.  RS-232C  INTERFACE  PIN  CONNECTIONS  on  page  224  show 
the  pin  connections  for  the  RS-232C  interface.   [Ref  2:  p.  6S3] 

SSDR:  Solid  State  Data  Recorder.  This  device  stores  audio  data  in  magnetic  bubble 
memories.  It  accepts  conmiands  analogous  to  those  selected  by  pushing  a  button  on 
a  con\entional.  reel-to-reel  tape  recorder.  For  example,  the  commands  PLAY  and 
RECORD  exist.    However,  access  to  the  data  can  be  random. 

Static:  In  C.  most  variables  are  dynamic  [q.':.\  They  can  be  made  sialic  by  the  inclu- 
sion of  this  keword  in  their  declarations.  This  causes  them  to  become  permanent. 
They  are  not  then  created  when  the  function  in  which  they  are  declared  starts  to  exe- 
cute. They  are  created  at  the  time  of  compilation.  They  do  not  lose  their  contents 
when  that  function's  operation  ends.  The  contents  of  the  storage  locations  assigned 
to  them  remain  intact  until  the  next  time  that  function  tries  to  access  that  variable. 

UART  (Universal  Asynchronous  Receiver-Transmitter):  A  common  integrated  circuit 
which  provides  asynchronous  communications  between  two  hardware  devices.  We  use 
it  to  implement  an  RS-232C  serial  interface  between  the  controller  hardware  and  a 
terminal. 

Volatile  Memon.-  Storage:  Conventional  R.AM  {q.\.)  loses  its  contents  when  power  is 
removed.  This  property  is  called  volatility.  By  contrast,  magnetic  core  and  bubble 
memories  are  non-volatile.  For  that  matter,  printed  pages  are  also  non-volatile 
memories. 

Voltage  Controlled  Oscillator  (\CO):  The  VCO  operates  a  loudspeaker  in  the  exper- 
iment during  the  sweep  phase.  The  frequencies  are  increased  incrementally  between 
35  Hz  and  785  Hz  in  1  Hz  increments. 
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I.     INTRODUCTION 

Since  it  began  flying  into  space  in  April,  1981  the  Space  Shuttle  has  made  it  much 
easier  to  get  payloads  into  space.  Although  the  shuttle  was  grounded  because  of  the 
tragic  explosion  of  the  Challenger  on  January-  28,  1986,  flights  resumed  in  October,  1988. 

A.     GET  AWAY  SPECIAL  (GAS) 

In  1976  the  National  Aeronautics  and  Space  Administration  (NASA)  established  the 
Get  Away  Special  (GAS)  program  [Ref.  3:  p. 11].  The  purpose  of  this  program  is  to 
permit  individual  experimenters  to  have  room  on  the  Space  Shuttle  for  their  experiments, 
provided  there  is  no  undue  interference  with  the  rest  of  the  mission  as  a  result.  To  pre- 
clude such  interference.  NASA  therefore  imposes  a  number  of  constraints  on  these  ex- 
periments.  Among  these  are 

1.  Thev  must  contain  their  own  power  source,  heatinc.  data  handling  facilities,  and 
so  on  [Ref  4:  p.S]. 

2.  No  more  than  three  external  switches  may  be  provided  for  operation  by  crew 
members.  Of  these,  one  must  be  devoted  to  removins  all  power  from  the  pavload 
[Ref  -I:  p.  :S]. 

The  Space  Shuttle  is  subject  to  powerful  acoustic  vibrations  during  launch.  In  the 
past,  minor  breakage  of  crystals  and  circuit  boards  has  resulted  (Ref  ?:  p.  11].  It  is 
thought  that  the  vibrations  are  responsible  for  this  damage,  and  that  some  regions  of  the 
cargo  bay  are  more  susceptible  to  damage  than  others.  Acoustical  analysis  of  the  sound 
waves  which  cause  these  vibrations  could  reveal  where  the  best  and  worst  locations  are. 

Several  early  GAS  experiments  carried  conventional  reel-to-reel  tape  recorders  and 
were  intended  to  record  the  acoustic  wa\es  in  the  cargo  bay  for  subsequent  analysis. 
However,  the  analysis  was  flawed  for  several  reasons  [Ref  5:  p.  15].  Among  these  were: 

1.  The  microphones  were  mounted  close  to  the  bulkhead  of  the  cargo  bay.  within  a 
partial  enclosure.    Thus  the  data  might  have  been  erroneous. 

2.  The  data  recorded  by  the  microphone  may  have  been  contaminated  by  interaction 
between  the  microphone  and  its  isolation  system. 

3.  The  acoustical  waves  in  the  forward  third  of  the  cargo  bay  were  not  recorded. 

Furthermore,  astronauts  were  too  busy  at  launch  time  personally  to  initiate  the  exper- 
iments. Instead,  the  experiments  included  circuitry  to  detect  the  roar  of  the  main  engines 
and  trigger  the  commencement  of  the  experiment  [Ref  6:  p.  11].    There  is  good  reason 


to  doubt  the  validity  of  the  analysis  of  acoustic  waves  whose  collection  was  itself  trig- 
gered by  the  occurrence  of  those  same  waves.  As  a  result  of  all  these  factors,  the  anal- 
ysis so  far  has  been  ambiguous. 

B.  THE  VIBRO-ACOUSTIC  EXPERIMENT 

The  Space  Systems  Academic  Group  at  the  Naval  Postgraduate  School  plans  to 
conduct  an  experiment  as  NASA  project  G-313  to  obtain  improved  acoustical  meas- 
urements in  the  cargo  bay  of  the  Space  Shuttle  during  launch.  In  the  remainder  of  this 
thesis,  we  shall  refer  to  this  project  as  the  Vibro-acoustic  Experiment.  The  reader  is  re- 
ferred to  [Ref  7]  for  a  general  overview  of  the  experiment. 

The  purpose  of  this  thesis  is  to  describe  the  software  and  some  of  the  hardware 
which  controls  the  Vibro-acoustic  Experiment.  At  times  this  thesis  will  merely  describe 
the  work  we  have  done.  At  other  times,  it  will  prescribe  what  to  do  to  achieve  various 
ends.  Thus  it  will  serve  not  merely  as  documentation  of  what  has  been  done,  but  it  will 
also  serve  as  a  manual  for  those  who  might  wish  to  elaborate  on  this  earlier  work. 

The  majority  of  the  work  performed  by  the  author  had  to  do  merely  with  the  control 
of  the  experiment.  However,  the  matched  filler  (described  in  Chapter  III.  THE 
MATCHED  FILTER  on  page  21)  was  redesigned  by  the  author  and  is  completely  de- 
scribed in  this  thesis. 

A  great  deal  of  the  hardware  and  software  created  to  control  the  Vibro-acoustic 
experiment  is  ver\'  general  in  nature,  and  would  apply  without  change  to  other  exper- 
iments. We  will  attempt  to  indicate  which  components  have  general  applicability.  The 
hope  is  that  future  applications  will  benefit  from  this  approach,  and  will  be  spared  the 
need  to  build  and  program  a  controller  from  scratch.  More  information  on  the 
general-purpose  controller  hardware  we  use  in  the  Vibro-acoustic  Experiment  can  be 
found  in  Chapter  II.  CONTROL  HARDWARE  on  page  10.  The  software  is  described 
in  general  terms  in  Chapter  IV.  DESIGN  OF  THE  CONTROL  SOFTWARE  on  page 
43. 

C.  DIFFERENCES  FROM  EARLIER  EFFORTS 

Like  earlier  experiments,  this  one  is  housed  in  a  GAS  canister.   It  differs  from  them, 
however,  in  several  key  respects. 
1.     Isolation  of  Microphones 

The  experiment  uses  microphones  housed  in  a  mounting  designed  at  the  Naval 
Postgraduate  School  to  isolate  them  from  vibration.     This  is  intended  to  reduce  the 


coniaminaiion  of  liie  recorded  acoustical  waves  by  structural  vibrations.  This  micro- 
phone arrangement  is  described  in  Stehle  [Ref.  5]. 

2.  Solid  State  Data  Recorder  (SSDR)  Using  Bubble  Memory 

Conventional  reel-to-reel  tape  recorders  are  supplanted  by  a  recorder  using 
magnetic  bubble  storage.  This  recorder  u'as  also  designed  at  the  Naval  Postgraduate 
School  and  has  the  following  advantages  over  conventional  recorders. 

1.  It  contains  no  moving  parts,  so  is  less  prone  to  mechanical  failure. 

2.  It  permits  random  access  to  data,  not  possible  with  tape.  While  such  a  capability 
is  commonplace  with  disk  storage,  disks  do  suffer  from  mechanical  breakdown. 
Also,  they  are  vulnerable  to  errors  when  external  accelerations  occur,  as  they  do 
during  a  launch.   This  is  less  problematic  in  the  case  of  bubble  memories. 

3.  Bubble  mcmor>-  is  non-volatile,  that  is,  its  contents  are  not  destroyed  when  power 
is  removed.  Thus  battery  power  is  not  required  to  keep  the  stored  data  available. 
Slightly  offsetting  this  advantage  is  the  fact  that  power  must  be  removed  in  a  con- 
trolled fashion,  and  specified  temperature  limits  must  be  maintained. 

The  magnetic  bubble  recorder  is  described  in  Frey  [Ref  S). 

3.  Microprocessor  Control  of  the  Experiment 

To  operate  the  experiment,  another  group  at  the  Naval  Postgraduate  School 
built  a  single-board,  microprocessor-based  controller.  This  general-purpose  controller 
uses  a  National  Semiconductor  NSCSOO  microprocessor  (roughly  equivalent  in  function 
to  a  Zilog  Z-SO).  This  controller,  as  it  was  originally  conceived,  is  described  in  Wallin 
[Ref  3].  From  a  programmer's  standpoint,  the  controller  has  the  characteristics  de- 
scribed in  Chapter  II.  Section  A.     Standard  Controller  on  page  10. 

The  controller  will  be  responsible  for: 

1.  activating  all  subsystems  at  the  appropriate  time; 

2.  monitoring  execution  of  the  experiment; 

3.  keeping  a  log  of  significant  events  and  the  dates  and  times  at  which  they  occurred. 
This  log  is  stored  m  the  controller's  bubble  memor>-  module; 

4.  recording  temperature  and  voltage  readings  while  the  shuttle  is  in  space;  and 

5.  ensuring  that  the  bubble  memories  do  not  get  too  cold.  This  is  done  by 
intermittentlv  operating  the  heater  subsystem  to  maintain  a  temperature  above 
lO'C.  [Ref.'l:  p.  3] 

In  addition  to  the  obvious  functions  called  for  in  controlling  the  experiment,  the  soft- 
ware also  contains  a  menu-driven  diagnostic  subsystem  to  provide  for  testing  on  the 
ground.    -Sec  APPENDIX  B.     CHOICE  OF  A  SOFTWARE  DEVELOPMENT  SYS- 


TEM  on  page  83  for  a  general  description  of  the  several  software  development  systems 
we  have  used.) 

D.     PROCEDURAL  OUTLINE  OF  THE  VIBRO-ACOUSTIC  EXPERIMENT 

In  this  section  we  sketch  an  outline  of  the  operation  of  the  Vibro-acoustic  Exper- 
iment. The  flowcharts  in  Chapter  IV,  Section  2.  Performing  the  Experiment  on  page 
46  show  the  procedure  which  the  experiment  follows.  A  synopsis  of  this  procedure  is 
provided  here.i  The  experiment  begins  to  operate  when  the  ground  crew  or  astronauts 
turn  on  a  switch  in  the  cabin,  causing  power  to  be  applied  to  the  GAS  canister  which 
houses  the  experiment.  With  power  applied,  the  microprocessor  comes  to  life.  Its  first 
task  is  to  initialize  the  programmable  hardware  ports  and  timers.  It  then  has  to  decide 
whether  or  not  to  perform  the  complete  experiment  or  an  abridged  version  of  it.  The 
need  for  such  a  decision  will  become  apparent  presently.  For  the  moment  we  will  con- 
fine our  attention  to  the  unabridged  experiment. 

1.  S^^eep  Phase 

Once  the  cargo  bay  has  been  loaded,  the  ground  crew  will  activate  the  exper- 
iment for  about  an  hour  to  let  it  perform  the  sweep  phase.  During  this  phase,  the  cargo 
bay  is  irradiated  with  a  sequence  of  acoustic  tones  of  known  frequencies  and  the  acoustic 
response  of  the  enclosure  is  recorded  by  the  Solid  State  Digital  Recorder  (SSDR).  After 
the  mission,  analyzing  this  data  [Ref  9]  and  comparing  it  to  the  echoes  recorded  during 
launch  will  reveal  the  locations  of  the  regions  most  and  least  prone  to  damage  from  vi- 
bration.  This  phase  is  the  longest,  and  lasts  13  minutes. 

2.  Detection  of  the  AuAiliar}'  Power  Units  (APUs) 

The  Space  Shuttle's  Auxiliary  Power  Units  (APUs)  are  jet  turbines  used  to  op- 
erate control  surfaces  during  launch  and  recover}-  of  the  shuttle.  The  APUs  start  to 
operate  around  five  minutes  before  launch.  Because  they  emit  a  characteristic  frequency 
at  600  Hz,  we  can  use  a  matched  fiher  to  detect  their  acoustic  signature 
[Ref  6:  pp.  15-18].  When  the  matched  filter  detects  this  signal,  it  knows  that  launch 
is  imminent,  and  it  is  time  to  start  recording  the  sounds  which  occur  prior  to  launch. 
Thus  we  will  record  the  sounds  before,  during,  and  after  launch.  By  not  waiting  for  the 
roar  of  the  main  rocket  engines  before  starting  to  record  the  ambient  noise,  we  will  avoid 
the  problem  mentioned  in  Chapter  I,  Section  A.  Get  Away  Special  (GAS)  on  page  1. 
The  data  collected  by  this  means  should  be  much  more  accurate. 


1  See  Chapter  IV,  Section  B.     Operation  of  the  Vibro-acoustic  Experiment  on  page  45  for 
complete  details. 


Since  there  exists  the  possibility  that  for  some  reason  the  matched  filter  will  fail 
to  detect  the  APUs.  the  experiment  includes  two  backup  systems. 

1.  The  Vibration-activated  Launch  Detector  will  detect  the  vibrations  associated  with 
launch. 

2.  A  second  backup  system  will  use  two  barometric  pressure  switches  to  detect  the 
drop  in  atmospheric  pressure  which  occurs  as  the  Space  Shuttle  rises.  These 
switches  will  be  placed  in  a  redundant,  parallel  configuration.  Thus,  if  either  one 
or  both  of  them  work,  the  drop  in  barometric  pressure  will  be  detected. 

Neither  of  these  systems  can  detect  operation  of  the  APUs.  However,  if  either  one 
should  detect  a  launch,  the  control  program  stops  waiting  for  the  APUs  to  come  on  and 
switches  immediately  to  the  launch  phase. 

If  the  matched  filter  successfully  detects  the  .APUs  but  the  Vibration-activated 
Launch  Detector  fails  to  detect  launch,  the  barometric  sensor  will  cause  the  experiment 
to  switch  to  launch  phase,  albeit  a  little  late. 

It  would  be  unfonunate  if  the  matched  filter  failed  to  detect  the  APUs.  for  then 
one  of  the  priman.-  advantages  of  the  Vibro-acoustic  Experiment  over  earlier  efforts  to 
record  acoustical  noise  in  the  Space  Shuttle  would  disappear.  It  would  be  doubly  un- 
fortunate ii^  neither  the  matched  filter  nor  the  vibration  detection  subsystem  worked,  for 
then  no  data  would  be  recorded  until  well  after  launch.  If  any  one  of  the  three  systems 
v.orks  as  designed,  then  the  experiment  will  acquire  at  least  soine  data. 

3.  Scroll  Phase 

If  the  matched  filter  detects  the  APUs.  the  control  program  will  place  the  Solid 
State  Data  Recorder  (SSDR)  into  scroll  mode.  In  this  mode,  the  SSDR  uses  a  subset 
of  its  bubble  memon.'  for  recording  the  ambient  noise  prior  to  launch.  The  fraction  of 
memor>-  dedicated  to  this  purpose  permits  at  most  1 10  seconds  of  recording  time.  Once 
this  memor.  is  u<:ed  up.  the  SSDR  will  start  re-u<ing  it  from  the  beginning.-  As  a  result 
of  this  mode  of  operation,  roughly  two  minutes  of  pre-launch  noise  will  be  recorded, 
along  with  the  noise  of  the  ignition  of  the  main  engines. 

4.  Launch  Phase 

Either  the  vibration  detection  subsystem  or  the  barometric  sensors  can  trigger 
detection  of  a  launch.  When  a  launch  is  detected,  the  control  program  puts  the  SSDR 
into  launch  mode.  The  purpose  of  this  mode  is  to  record  the  noise  after  the  launch  be- 
gins.    In  launch  mode,  enough  memor>-  is  dedicated  to  permit  about  two  minutes  of 


2  In  eflect.  the  SSDR  is  writing  onto  a  continuous,  looped  scroll,  hence  the  name  of  this  mode 
of  operation. 


ambient  noise  to  be  recorded. 3  Once  this  memory-  is  exhausted,  the  SSDR  will  signal  the 
control  program  that  it  has  finished  operations. 

5.  Post-launch  Operations 

After  the  SSDR  has  signalled  completion,  the  Vibro-acoustic  Experiment  has 
finished  gathering  all  the  acoustical  data  it  needs.  The  controller  will  continue,  however, 
to  monitor  and  record  temperature  in  the  GAS  canister  and  record  this  information  in 
its  own  bubble  memon.'  module.  It  will  also  monitor  and  record  voltage  levels  of  each 
of  three  power  supply  batteries.  If  these  should  fall  below  8.5V,  it  will  halt.  This  pre- 
vents loss  of  data  in  the  bubble  memory  due  to  insufficient  voltage  and  current  levels. 

The  basis  for  choosing  8.5V  follows.  Each  individual  cell  is  rated  for  2.0V. 
There  are  fwQ  of  these  cells  in  the  10  V  stack  which  powers  the  bubble  memory.  If  any 
cell  drops  to  1.81V  or  below,  it  is  considered  to  be  below  the  operating  threshold.  Five 
such  cells  generate  9.05V.  The  bubble  memory  itself  can  operate  on  as  little  as  5  V. 
We  know  that  the  batteries  are  losing  power  when  the  voltage  falls  below  8.5  V.  but  we 
still  have  a  margin  of  3.5  V  abo\e  the  \ oltage  required  to  operate  the  bubble  meniory. 
(The  margin  is  reduced  slightly  due  to  the  presence  of  5  V  voltage  regulators  in  the  cir- 
cuit, but  it  is  still  ample.)  It  is  therefore  reasonable  to  halt  operations  if  the  voltage  falls 
below  8.5V  . 

Also,  if  the  temperature  of  the  bubble  memory  falls  below  10°C.  it  is  below  the 
minimum  operating  temperature,  and  we  will  suspend  operation  of  the  bubble  memory 
until  the  temperature  returns  to  10°C  once  more.  Likewise,  if  the  temperature  should 
rise  above  55°C,  it  is  above  the  maximum  operating  temperature,  and  bubble  memory^ 
operations  will  be  suspended  until  the  temperature  drops  within  the  operating  range 
again.-*  [Ref  1:  Chapter  1.  p.  3] 

6.  Abridged  Experiment 

NASA  has  balked  at  the  idea  of  our  performing  the  sweep  phase.  They  are 
concerned  over  the  possibihty  that  the  loud  sounds  generated  during  the  sweep  might 
damage  other  payloads  or  frighten  technicians.    They  also  are  reluctant  to  remove  per- 


3  Since  the  shuttle's  cargo  bay  is  not  pressurized,  the  air  will  leak  out  as  the  outside  pressure 
drops.  After  two  minutes,  there  will  be  no  appreciable  atmosphere  left  inside  the  cargo  bay,  and 
all  sound  will  have  ceased. 

4  These  checks  are  only  performed  during  the  post-launch  phase,  which  begins  within  two  or 
three  minutes  from  the  time  of  launch.  It  is  unlikely  that  NASA  would  launch  the  shuttle  if  the 
outside  temperature  were  below  lO'C,  and  we  do  not  anticipate  that  the  temperature  will  fall 
appreciably  within  the  first  three  minutes  of  flight. 


sonnel  from  the  vicinity  of  the  shuttle  during  that  phase.  They  are  equally  reluctant  to 
require  those  personnel  to  wear  hearing  protection  during  the  sweep. 

Those  arguments  seem  specious  to  us.  It  strikes  us  as  unlikely  that  damage  to 
equipment  might  result  from  the  sweep  but  not  from  the  rocket  motor  noise  during  lift 
off.  We  cannot  see  the  reason  why  personnel  whose  hearing  might  be  damaged  during 
the  sweep  cannot  wear  hearing  protection.  While  we  can  still  perform  an  analysis  of  the 
recorded  data  without  first  doing  a  sweep,  it  is  likely  to  produce  less  useful  results. 

We  have  decided  to  proceed  as  we  wanted  to  originally,  that  is,  to  design  an 
experiment  which  would  do  everything  we  want.  We  have  added  an  additional  decision 
point  to  permit  the  abridged  experiment  to  take  place.  This  shortened  experiment  would 
simply  turn  on  the  recorder  when  the  APL's  were  detected  or  when  launch  occurred,  and 
we  would  hope  for  the  best.  There  would  be  no  sweep,  no  scroll,  and  no  launch  phases: 
there  would  only  be  a  record  phase,  once  the  APL  s  or  a  launch  were  detected. 

Once  NASA  sees  that  the  abridged  experiment  works,  that  the  analysis  provides 
good  results,  and  that  permitting  the  unabridged  experiment  will  yield  even  better  data, 
we  hope  that  they  will  relent  and  permit  us  to  lly  the  experiment  again  in  the  unabridged 
mode. 

E.     IRREGULARITIES 

What  happens  if  the  power  fails  temporarily  and  then  is  restored?  This  might  hap- 
pen if  the  power  switch  is  inadvertently  switched  olf  by  the  ground  or  flight  crew,  or 
through  some  equipment  malfunction.  Upon  the  restoration  of  power,  the  micro- 
processor must  decide  where  in  its  procedure  to  resume  execution.  There  are  several 
cases  to  consider. 

1.  The  sweep  phase  has  never  been  initiated,  nor  has  a  launch  occurred.  The  correct 
action  is  to  start  at  the  beginning. 

2.  The  sweep  phase  has  been  initiated.  It  is  not  known  whether  or  not  it  ever  was 
completed,  but  a  launch  has  not  occurred.  The  correct  action  is  to  skip  the  sweep 
phase  and  wait  for  some  indication  of  a  launch.  The  sweep  creates  a  very  loud 
noise  which  would  be  hazardous  to  ground  personnel  if  it  were  permitted  to  occur 
at  other  than  a  scheduled  time.  Since  this  time  is  not  known  at  present,  and  never 
is  firmJy  enough  known  in  advance  to  be  programmed  into  the  computer,  we  can- 
not risk  running  the  sweep  phase  if  it  is  interrupted  by  a  power  fault. 

3.  The  sweep  phase  has  been  initiated  (and  presumably  completed),  the  APUs  are  on, 
but  no  indications  of  a  launch  are  present.  The  correct  action  is  to  enter  scroll 
mode.  If  it  was  already  in  progress  when  the  power  fault  occurred,  it  will  be  re- 
started.  This  is  all  right,  since  no  vital  information  will  be  lost  by  this  procedure. 

4.  The  sweep  phase  has  been  initiated  (and  presumably  completed)  and  conditions  of 
a  launch  are  present  but  the  barometric  switch  has  never  been  tripped.  The  correct 


action  is  to  assume  we  are  just  beginning  a  launch  and  to  initiate  launch  mode. 
This  creates  a  risk  that  recordings  of  the  moment  of  launch  would  be  lost  if  a  power 
fault  occurred  between  the  moment  of  launch  and  the  triggering  of  the  barometric 
switch  as  the  spacecraft  ascends.  There  is  no  obvious  way  entirely  to  ehminate  this 
risk. 

5.  The  sweep  phase  was  initiated  (and  presumably  completed)  and  the  barometric 
switches  were  activated  at  some  earlier  point.  This  implies  that  the  power  fault 
took  place  after  the  activation  of  the  barometric  switches,  that  is,  after  launch.  The 
correct  action  is  to  assume  that  launch  data  was  successfully  recorded  and  to  initi- 
ate the  post-launch  monitoring  operations. 

F.     OTHER  APPLICATIONS 

The  controller  hardware  is  sufficiently  powerful  that  it  could  easily  provide  control 
for  other  applications.  In  particular,  many  spaceborne  applications  could  be  operated 
by  it. 

In  the  course  of  developing  the  control  software,  we  had  to  create  support  routines 
to  take  care  of  a  great  many  mundane  functions.  In  computers  with  operating  systems, 
these  functions  are  typically  provided  by  the  operating  system.  The  user  has  merely  to 
know  about  them  and  use  them. 

The  controller  we  use  has  no  operating  system,  so  we  had  to  create  many  low-level 
functions,  t?.^..  one  which  converts  a  hexadecimal  number  to  a  character  string  repres- 
enting that  number. 

At  a  higher  level,  we  wrote  subroutines  to  display  text  on  a  terminal,  operate  a 
bubble  memory,  operate  a  real-time  clock,  and  control  various  external  devices  through 
the  44  input  and  output  lines  provided  with  the  controller. 

By  using  the  low-level  subroutines,  and  by  organizing  an  apphcation's  software  in 
a  similar  manner,  much  of  the  most  tedious  and  uninspiring  work  entailed  in  producing 
a  control  program  for  this  controller  hardware  could  be  avoided.  This  would  leave  more 
time  to  devote  to  the  real  purpose  of  the  appUcation.  In  an  environment  with  few  people 
available  to  do  the  work,  such  economy  is  ver\'  attractive. 

Another  consideration  is  the  lack  of  a  need  to  use  assembly  language  in  program- 
ming the  controller.  In  the  ver\-  few  places  where  it  was  required,  we  used  it.  Along 
with  the  large  collection  of  C  language  subroutines  of  general  appHcabihty,  the  routines 
we  have  already  provided  in  assembly  language  should  suffice  for  almost  all  run-of-the- 
mill  work. 

In  one  area  we  were  ourselves  compelled  to  abandon  the  use  of  C  language  source 
code  and  switch  to  assembly  language  code.  We  initially  hoped  that  only  the  start-up 
code,  the  input  routine,  the  output  routine  and  the  software  delay  routine  would  require 


the  use  of  assembly  code.  We  assumed  we  could  input  from  and  output  to  the  bubble 
memon"  using  compiled  C  language  source  code. 

This  assumption  turned  out  to  be  incorrect.  We  needed  a  data  transfer  rate  of 
16.000  bytes  per  second  [Ref  1:  Chapter  1,  p.  3],  but  could  only  attain  around  3.000 
bytes  per  second.  Consequently,  we  had  to  replace  a  small  section  of  C  code  with  as- 
sembly language  source  code.  Even  this  was  necessar\'  only  because  we  used  a  proioiype 
bubble  memon.-  board  with  a  buffer  whose  size  was  inadequate  to  handle  data  transfers. 
While  this  buffer  provided  only  40  characters  of  space,  we  needed  64. 

When  speed  becomes  paramount,  assembly  code  may  be  necessary,  since  it  can  be 
tailored  to  the  job  at  hand  and  so  produce  ver\'  efficient  programs.?  For  many  applica- 
tions, however,  speed  is  not  critical.  It  ordinarily  is  foolish  to  waste  time  achieving  in 
assembly  language  what  can  be  done  much  more  quickly  using  a  high-level  language. 
Only  if  you  cannot  achieve  the  desired  performance  with  a  high-level  language,  must  you 
use  assembly  language. 

Irrespective  of  whether  some  portion  of  an  application  does  or  does  not  demand 
efficient  code  (written  in  assembly  language),  for  most  applications  the  majority  of  the 
code  can  be  written  in  a  high-level  language  such  as  C.  Many  applications,  too,  need 
no  more  facilities  than  those  provided  in  the  Vibro-acoustic  Experiment.  In  such  cases, 
building  on  the  work  presented  in  this  thesis  has  verv'  clear  advantages. 


5  Nonetheless,  some  optimizing  compilers  surpass  quite  competent  assembly  language  pro- 
srammers  in  efficiency. 


II.     CONTROL  HARDWARE 

The  controller  we  use  in  the  Vibro-acoustic  Experiment  is  based  on  the  NSC800 
microprocessor.  For  all  practical  purposes,  this  is  functionally  equivalent  to  the  Zilog 
Z-806  [Ref.  10].  Figure  1  on  page  11  is  a  block  diagram  showing  the  major  components 
of  the  system.  To  the  left  of  the  microprocessor  appear  those  peripherals  which  ordi- 
narily fall  under  the  control  of  the  standard  controller.  We  discuss  these  peripherals  and 
their  capabilities  in  Section  A.  Standard  Controller  below.  One  can  connect  an  assort- 
ment of  devices  to  the  44  input  and  output  lines  available  on  it.  Other  applications  than 
the  Vibro-acoustic  experiment  could  use  this  bare-bones  controller  for  their  own  pur- 
poses. 

To  the  right  of  the  microprocessor  appear  those  peripherals  which  are  peculiar  to 
the  Vibro-acoustic  Experiment.  We  discuss  these  peripherals  and  their  capabilities  in 
Section  B.     Additional  Controller  Hardware  on  page  14  below. 

A.     STANDARD  CONTROLLER 
1.     NSC810A  RAM-I/O-Timers 

Two  NSCSIOA  R.-\M-I  0-Timer  units  provide  four  eight-bit  ports  and  two  six- 
bit  ports.  These  provide  44  bits  of  input  and  output  capability.  There  also  are  two 
timers  on  each  device.  One  of  each  pair  is  completely  independent  of  the  data  ports;  the 
other,  if  used,  reduces  the  number  of  available  pins  in  the  six-bit  port  to  three.  We  have 
configured  the  system  such  that  one  of  the  latter  kind  of  timer  is  unavailable,  since  we 
have  dedicated  the  data  lines  with  which  it  interferes  to  other  purposes.  The  two  timers 
which  do  not  conflict  with  any  data  lines  at  all  are  dedicated  to  providing: 

1.  A  153.6  kHz  signal  to  the  IM6402  Universal  Asynchronous  Receiver  Transmitter 
(UART)  where  it  is  divided  by  16  to  yield  a  %00  BAUD  clock  for  serial  data 
transmission. 

2.  A  614.4  kHz  clock  which  is  provided  to  the  ADC0816  Analog-to-Digital  Converter. 

Thus  one  of  the  four  timers  is  available  for  other  uses. 

We  shall  hereafter  refer  to  the  two  devices  as  NSCSIOA  #1  and  NSCSIOA  #2 
respectively.    The  NSCSIOA    reference  manual  [Ref.  11]  refers  to  the  eight-bit  ports  by 


6  The  \SC800  includes  several  instructions  not  included  with  the  Z-80.   Since  the  Z-80  is  the 
better-known  device,  we  have  not  used  any  of  the  added  instructions. 
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Figure   1.      Block  diagram  of  major  components  of  the  \  ihro-acoustic  Experiment. 


the  letters  A  and  B,  and  to  the  six-bit  port  by  the  letter  C.  In  the  rest  of  this  thesis,  when 
we  wish  to  distinguish  between  ports  on  NSCSIOA  «!  and  NSCSIOA  -2.  we  shall  ap- 
pend a  subscript  to  the  port's  letter,  e.g.,A^  is  NSCSIOA  #1,  port  A. 

NSCSIOA  #1  uses  port  addresses  0x00  through  0x19.7  NSCSIOA  ^2  uses  port 
addresses  0x20  through  0x39.8 

General  information  on  programming  the  NSCSIOA  can  be  found  in  [Ref  11]. 
We  present  the  specific  manner  in  which  these  devices  have  been  programmed  for  the 
Vibro-acoustic  Experiment  in  Section  A.  Major  Subroutines  and  Functions  on  page 
lOS. 

2.  On-board  Analog-to-digital  Converter 

An  eight-bit,  16-channel.  National  Semiconductor  ADC0S16  analog-to-digital 
{A  D)  converter  permits  the  monitoring  of  voltages  and  temperatures  at  various  points 
within  the  experiment.  It  can  be  mounted  right  on  the  microprocessor-based  controller 
board.  The  device  is  connected  starting  at  input  output  space  address  OxSO.  Conversion 
of  an  analog  input  to  a  digital  number  is  signalled  to  the  control  program  by  the  exist- 
ence of  a  1  in  bit  3  of  port  C,. 

3.  Bubble  Memory  Module  for  the  Controller 

Devoted  to  the  use  of  the  controller  board  is  a  512  KByte  Intel  BPK  5V75A 
Four-Megabit  Bubble  Memory  Prototype  Kit.  The  control  program  will  maintain  a  log 
in  this  memory  of  all  actions  it  takes  during  the  experiment.  The  information  will  in- 
clude a  code  signifying  the  action  taken,  the  time  and  date  of  that  action,  and  the  current 
temperature  and  voltage  readings. 

After  launch,  the  Vibro-acoustic  Experiment  is  over.  The  control  program  then 
uses  the  log  so!t!y  for  the  purpose  of  recording  temperatures  and  voltages. 

Port  address  0.x40  provides  access  to  the  bubble  memory.  There  are  8192  pages 
of  64  bytes  per  page.    Pages  of  the  bubble  memory  can  be  specified  at  random  by  num- 


7  The  term  "port"  is  somewhat  ambiguous.  The  NSCSIOA  reference  manual  [Ref  1 1]  refers 
to  a  collection  of  pins  within  an  NSCSIOA  integrated  circuit  as  a  port.  This  particular  device 
contains  three  ports:  A.  B  and  C.  In  common  parlance,  however,  the  term  port  refers  to  a  par- 
ticular address  in  the  input-output  address  space  (1,0  space)  of  the  Z-80.  This  space  spans  ad- 
dresses from  0x00  through  OxIT.  We  might  say,  for  example,  that  we  perform  an  input  operation 
from  port  Ox  la.  This  is  equi\alent  to  saying  we  input  a  bUe  (character)  from  I  O  space  address 
Ox  la.  We  shall  seldom  attempt  explicitly  to  state  which  use  is  intended.  The  meaning  may  gener- 
ally be  ascertained  from  the  conte.xt. 

8  See  the  discussion  on  hexadecimal  notation  in  the  Glossarv. 


bers  from  0  through  8191.     Port  address  0x41  provides  control  information  for  this 
memory  dcsice. 

The  bubble  memory's  reset  line  should  be  brought  low  by  placing  a  0  in  bit  5 
of  port  Cj  before  applying  power  to  or  removing  power  from  the  bubble  memor}-.  It  is 
important  to  wait  at  least  50  ms  after  applying  power  before  attempting  to  initialize  the 
bubble  memor>"  [Ref.  1:   Chapter  4,  p.  3]. 

Power  can  then  be  applied  to  the  bubble  memor}-  by  putting  a  1  in  bit  4  of  port 
C,.    Putting  a  0  there  removes  power. 

Details  of  the  operation  of  this  memory  and  the  meaning  of  the  control  byte 
information  are  in  [Ref  1].   We  describe  the  manner  in  which  we  have  programmed  the 
bubble  memor>-  to  support  the  Vibro-acoustic  E.xperiment  in  Section  A.     Major  Sub- 
rouiipies  and  Functions  on  page  108. 
-1.     Real  Time  Clock 

A  National  Semiconductor  MM5S167A  real  time  clock  makes  it  possible  to  re- 
cord in  the  log  of  events  the  dates  and  times  of  all  actions  taken.  We  also  use  this  device 
to  limit  the  amount  of  time  the  control  program  waits  for  various  events  to  occur.  If  the 
event  does  noi  occur  for  some  reason,  the  control  program  decides  to  stop  waiting. 

For  example,  once  the  Auxiliar>'  Power  Units  (APUs)  are  detected,  there  is  a 
window  of  about  seven  minutes  in  length.  If  launch  does  not  occur  within  this  window, 
the  launch  will  be  scrubbed  since  the  APL's  will  no  longer  have  sufTicient  fuel.  We  can 
therefore  regard  the  experiment  as  having  been  aborted  if  this  amount  of  time  passes 
without  a  launch.  We  use  the  real-time  clock  to  detect  the  passage  of  this  period  of  time. 
5.     RS-232C  Serial  Input/Output  Port 

.An  RS-232C  interface  provides  communication  with  a  serial  device  such  as  a 
terminal.  This  makes  it  feasible  to  monitor  and  control  the  system  on  the  ground.  By 
connecting  a  terminal  to  this  interface,  the  user  has  access  to  an  extensive,  menu-driven 
diagnostic  subsystem.  (This  menu  subsystem  is  dormant  if  there  is  no  terminal  at- 
tached.) No  intelligence  currently  is  required  on  the  part  of  the  terminal:  it  is  purely  a 
display  device. 9  Port  address  OxeO  holds  control  information  to  and  from  the  serial  de- 
vice. Port  address  OxcO  funnels  data  either  to  or  from  the  device.  Table  1  on  page  14 
shows  the  use  of  the  bits  of  the  control  port. 


9  Mr.  David  Rigmaiden  of  the  Space  Systems  Academic  Group  at  the  Naval  Postgraduate 
School  has  proposed  encodmg  the  diagnostic  messages  and  using  an  intelligent  terminal  to  display 
the  corresponding  human-readable  messages.   However,  no  one  has  yet  done  any  work  on  this. 


If  there  is  a  terminal  connected  to  the  RS-232C  Serial  port  at  addresses  Oxco 
and  OxeO.  then  bit  3  of  port  C,  will  be  a  1.  This  permits  the  control  program  to  distin- 
guish diagnostic  operation  on  the  ground  (when  there  will  be  a  terminal  attached)  from 
actual  performance  of  the  experiment  (when  there  vv/7/  not  be  a  terminal  attached.)  As 
can  be  seen  in  Figure  1  on  page  11,  the  Vibro-acoustic  Experiment  will  not  use  a  ter- 
minal when  it  is  in  space. 


Table   1.     ASSIGNMENT  OF   BITS   IN   THE   RS-232C   SERIAL   INTERFACE 
PORT:     This  port  uses  address  OxOe  for  control  information  and  OxOc  for 


Bit 

Direction  of 
Data  Flow 

Meaning 

0 

Input 

0  if  the  attached  device  can  accept  output  mior- 
mation.  1  otherwise. 

1 

Input 

1  if  the  attached  device  has  data  available.  0  oth- 
envise. 

B.     ADDITIONAL  CONTROLLER  HARDWARE 

The  Vibro-acoustic  Experiment  uses  several  subsystems  which  are  not  a  part  of  the 
standard  controller.  Most  of  these  subsystems  appear  to  the  right  of  the  microprocessor 
in  the  block  diagram  in  Figure  1  on  page  1 1.  The  only  one  which  does  not  is  the  Power 
Control  Subsystem,  which  is  drawn  below  the  microprocessor.  These  subsystems  have 
the  following  functions: 

\,     Analog-to-digital  Converter  Subsystems 

Three  A  D  converters  convert  the  analog  acoustical  signal  detected  by  a  set  of 
three  microphones  into  the  digital  format  required  by  the  Solid  State  Data  Recorder 
(SSDR).   The  design  and  operation  of  the  SSDR  is  provided  in  [Ref  9]. 
2.     Solid  State  Data  Recorder  (SSDR) 

The  SSDR  is  comparable  in  function  to  a  conventional  reel-to-reel  tape  re- 
corder. Unlike  a  standard  tape  recorder,  it  is  not  limited  to  sequential  operation;  it  can 
access  data  randomly.   The  operation  of  the  SSDR  is  more  fully  described  in  [Ref  8]. 

To  issue  a  command  to  the  SSDR,  place  its  code  in  port  A,  on  NSC810A  #1, 
located  at  I  O  space  addresses  0x00  through  0x19.  The  SSDR  will  place  a  status  code 
reflecting  its  operating  state  in  port  Aj  .   Table  4  on  page  17  defines  the  command  codes 


Table  2.  BIT  ASSIGNMENTS  FOR  READING  POWER  SUBSYSTEM  RELAY 
SETTINGS:  The  position  of  relays  may  be  determined  by  reading  port 
B,  (on  NSC810A  -2).  which  is  located  at  I  O  space  addresses  0x20  through 
0x39. 


Bit 

Direction 

of  Data 

Flow 

Value 

Meaning 

0 

Not  used.                                                        1 

1 

Input 

1 

The  Solid  State  Data  Recorder  (SSDR)  is  on 

0 

The  SSDR  is  oiW 

: 

Input 

1 

The  Voltage  Controlled  Oscillator  (VCO)  is  oil. 

N 

It  IS  olT 

Input 

1 

The  Analog  to  Digital  Conversion  (A  D)  cir- 
cuit is  on. 

1) 

It  1^  ofT. 

4 

Input 

1 

The  Matched  Filter  .  \'ibration-activated 
Launch  detector,  and  Barometric  Pressure 
Switches  are  on. 

'• 

It  IS  otT 

i^ 

Input 

1 

The  heater  circuit  is  on. 

0 

It  1^  ofT, 

for  the  SSDR.   Table  5  on  page  17  defines  the  status  codes  the  SSDR  can  return  to  the 

control  program.    The  following  SSDR  commands  are  of  particular  note: 

Sweep  Record  12.5  minutes  of  pre-determined  frequencies  emitted  by  the  Voltage 
Controlled  Oscillator  (VCO)  prior  to  launch. 

Scroll  Record  up  to  55  seconds  of  ambient  noise  during  the  five  minutes  or  so 
between  the  time  the  Auxiliar>-  Power  Units  (APUs)  come  on  and  the  time 
of  launch.  In  this  mode,  the  SSDR  will  continually  re-use  the  same  portion 
of  SSDR  memorv-.  There  are  two  sections  of  memory  devoted  to  this  pur- 
pose, and  use  alternates  between  them.  Each  can  hold  up  to  55  seconds  of 
ambient  noise.  When  the  SSDR  is  commanded  to  enter  launch  mode,  the 
memor>-  section  currently  in  use  will  be  filled  and  then  the  SSDR  will  switch 
over  to  that  section  of  memory  devoted  to  recording  post-launch  noise. 

Launch  The  experiment's  control  program  orders  the  SSDR  to  enter  launch  mode 
as  soon  as  the  Space  Shuttle  launches.  This  mode  lasts  for  two  minutes, 
which  is  about  the  time  it  takes  to  evacuate  the  air  from  inside  the 
shuttle's  cargo  bay.    During  this  mode,  the  SSDR  records  ambient  noise. 


Table  3.  BIT  ASSIGNMENTS  FOR  CONTROLLING  POWER  SUBSYSTEM 
RELAYS:  Relays  may  be  controlled  through  port  B,  (on  NSCSIOA  ?^l), 
which  is  located  at  I  O  space  addresses  0x00  through  0x19. 


Bit 

Direction 

of  Data 

Flow 

Value 

Meaning 

0 

Output 

1 

Turn  on  the  relays  specified  in  the  other  bit 
positions. 

0 

Turn  ofT  the  relays  specified  in  the  other  bit 
positions. 

■ 

Output 

1 

Operate  the  Solid  State  Data  Recorder 
(SSDR). 

0 

Do  not  operate  the  Solid  State  Data  Recorder 
(SSDR). 

2 

Output 

1 

Operate  the  Voltage  Controlled  Oscillator 
(VCO). 

0 

Do  not  operate  the  Voltage  Controlled 
Oscillator  (VCO). 

3 

Output 

I 

Operate  the  Analog  to  Digital  Conversion 
(.■\  D)  circuit. 

0 

Do  not  operate  the  Analog  to  Digital  Conver- 
sion (A  D)  circuit. 

4 

Output 

1 

Operate  the  Matched  Filter  (including 
accelerometer  and  barometric  <;\viich). 

0 

Do  not  operate  the  Matched  Filter. 

5 

Output 

1 

Select  the  heater  circuit. 

0 

Do  not  select  it. 

As  can  be  seen  in  the  flowchart  in  Figure  22  on  page  50,  most  of  the  experiment 
is  devoted  to  the  operation  of  the  SSDR,  that  is,  to  placing  it  in  the  mode  appropriate 
for  the  current  phase  of  the  Space  Shuttle's  mission. 
3.     Matched  Filter 

As  mentioned  in  Section  2.  Detection  of  the  Auxiliar>'  Power  Units  (APUs) 
on  page  4,  a  matched  filter  will  detect  the  characteristic  600  Hz  signature  of  the  APUs. 
This  device  will  place  a  1  in  bit  0  of  port  C,  if  a  detection  occurs.  Normally  it  leaves  a 
0  there.  Table  6  on  page  18  shows  the  uses  of  all  the  bits  of  Port  C,.  The  matched  filter 
is  described  in  Chapter  III.     THE  MATCHED  FILTER  on  page  21. 


Table  4.     SSDR  COMMAND  CODES:     Commands  are  issued  by  writmg  them  to 
port  A,  on  NSCSIO  =1.  located  at  I  O  space  addresses  0x00  through  0x19. 


Code 

\alue 

Meaning 

STANDBY 

0x01 

Commands  the  SSDR  to  cease  all  operations  and 
await  further  commands. 

SWEEP 

0x02 

Commands  the  SSDR  to  enter  sweep  mode. 
Enough  memory  is  available  for  holding  holding 
12.5  minutes  of  noise  generated  bv  the  VCO. 

SCROLL 

0x04 

Commands  the  SSDR  to  enter  scroll  mode. 
Enough  memor\-  is  available  for  holding  30  sec- 
onds of  ambient  noise. 

LALNCH 

0x0  S 

Commands  the  SSDR  to  enter  launch  mode. 
Enough  memory  is  available  for  holding  two 
minutes  of  ambient  noise. 

RECORD 

0x10 

Commands  the  SSDR  to  start  recording  noise. 
This  is  analagous  to  the  RECORD  button  on 
conventional  tape  recorders. 

PLAYBACK 

0x20 

Commands  the  SSDR  to  play  recorded  data  back. 
This  mode  is  analogous  to  the  PLAY  button  on 

conventional  tape  recorders. 

Table  5.     SSDR  STATUS  CODES:     Status  codes  may  be  obtained  by  reading  them 
from  port  A^  on  NSCSIO  =2.  located  at  I  O  space  addresses  0x20  through 


Code                     1           \  alue 

Meaning 

OPCOMP 

0x40 

Shows  that  the  SSDR  has  completed  the  last 
command  it  received. 

NORM op 

nxSii 

Shows  that  the  SSDR  is  operating  normallv. 

4.  Voltage  Controlled  Oscillator  (VCO) 

The  purpose  of  the  VCO  is  to  irradiate  the  shuttle's  cargo  bay  with  sound  of  a 
predetermined  frequency  during  the  sweep  phase.  This  is  done  by  applying  power  to  a 
loudspeaker.  The  VCO  is  designed  to  step  up  in  frequency  from  35  Hz  through  785  Hz 
in  1  Hz  steps.  By  recording  the  echoes,  subsequent  analysis  will  permit  a  comparison 
of  the  acoustical  response  of  the  pure  tone  to  that  of  the  noise  generated  during  launch. 

5.  Vibration-activated  Launch  Detector 

This  circuit  is  mounted  on  the  same  circuit  board  as  the  matched  filter.  Its 
purpose  is  to  enable  the  control  program  to  detect  a  launch,  and  so  enable  it  to  com- 


Table  6.     BIT  ASSIGNMENTS  IN  PORT  C,  OF  NSC810A  #1 


Bit 

Direction 

of  Data 

Flow 

Value 

Meaning 

0 

Input 

1 

Detection  of  the  Auxiliary  Power  Units  (APUs) 
has  occurred. 

0 

Detection  of  the  Auxiliary  Power  Units  (APUs) 
has  not  occurred. 

1 

Input 

1 

The  Vibration-activated  Launch  Detector  has 
detected  a  launch. 

0 

The  Vibration-activated  Launch  Detector  has 
not  detected  a  launch. 

2 

Input 

1 

One  of  the  barometric  pressure  switches  has 
detected  a  launch. 

0 

Neither  barometric  pressure  switch  has  de- 
tected a  launch. 

3 

Input 

1 

No  terminal  is  connected  to  the  port. 

0 

A  terminal  is  connected  to  the  RS-232C  serial 
interface  port. 

4 

Output 

1 

Order  the  power  subsystem  to  change  the 
states  of  the  relays  specified  in  the  command 
at  port  B, 

0 

Do  not  chanee  the  states  of  the  relavs. 

5 

Not  used.                                                         1 

mand  the  Solid  State  Data  Recorder  to  enter  launch  mode.  It  will  set  bit  1  of  port  Cj 
high  when  it  detects  a  launch  (see  Table  6  on  page  IS).  Even  if  the  matched  filter  never 
detects  the  APUs.  detection  of  launch  will  still  cause  the  control  program  to  force  the 
SSDR  into  launch  mode. 

6.     Barometric  pressure  switches 

On  the  same  circuit  board  as  the  matched  filter  there  are  two  barometric  pres- 
sure switches  connected  in  a  redundant,  parallel  configuration.  These  switches  serve  as 
a  backup  for  the  Vibration-activated  Launch  Detector.  Either  one  of  them  will  place  a 
high  voltage  in  bit  2  of  port  C,  (see  Table  6)  when  pressure  drops  below  27.9  inches  of 
mercur}-.  This  pressure  corresponds  to  an  ahitude  between  1500  feet  and  2000  feet  when 
the  lowest  barometric  pressures  on  record  at  Cape  Canaveral  are  present.    In  general, 


Table 


BIT  ASSIGNMEiNTS  IN  PORT  Q  OF  NSC810A  #2 


Bit 

Direction 

of  Data 

Flow 

\alue 

Meaning 

0 

Output 

1 

Operate  the  heater  subsystem. 

0 

Do  not  operate  the  heater  subsystem. 

1 

Not  used. 

2 

Not  used. 

3 

Input 

1 

Analog  to  digital  conversion  is  complete.   This 
refers  to  the  On-board  A  D  Converter  (see 
Figure  20  on  page  48 ». 

0 

Analog  to  digital  conversion  is  not  yet  com- 
plete. 

- 

Output 

1 

.Apply  power  to  the  bubble  menior}'. 

n 

Do  not  apply  power  to  the  bubble  memory. 

5 

Output 

1 

Do  not  apply  a  reset  signal  to  the  bubble 
nicmorv.    This  is  the  normal  setting. 

0 

Apply  a  reset  signal  to  the  bubble  memory. 
This  must  be  do^ne  while  power  is  applied  to 
or  removed  from  it.   Once  the  power  has  been 
switched  on  or  ofT.  the  reset  line  can  be  re- 
turned to  0. 

the  corresponding  altitude  will  be  somewhat  higher  than  this  since  barometric  pressures 
will  generally  not  be  at  their  lowest  when  NASA  launches  a  Space  Shuttle. 

7.  Heater  Circuit 

The  purpose  of  the  heaters  is  to  maintain  the  temperature  of  the  controller's 
bubble  memory  module  at  or  above  lO'C  during  operation,  and  above  -20X  otherwise. 
To  do  this,  there  are  heater  strips  attached  to  the  bubble  memory  module.  To  turn  on 
the  heaters,  the  control  program  places  a  1  in  bit  0  of  port  Cj.  It  puts  a  0  there  to  turn 
them  ofT.  InsufTicient  power  is  available  to  heat  all  the  bubble  memories  in  the  Solid 
State  Data  Recorder  (SSDR).  If  the  contents  of  the  log  are  saved,  however,  it  should 
at  least  be  possible  to  ascertain  the  cuse  of  the  loss  of  acoustic  data  in  the  SSDR. 

8.  Po>ver  Control  Subsystem 

Three  batteries  of  dry  cells,  each  powering  a  different  bus,  provide  power  to  the 
experiment.  Partly  in  order  to  conserve  power,  but  also  to  permit  isolation  of  subsys- 
tems if  an  overheat  condition  occurs,  most  subsystems  receive  power  only  when  neces- 


sar>'.  The  power  subsystem  includes  a  relay  for  each  of  these  other  subsystems.  By 
writing  appropriate  commands  to  port  B,  we  can  turn  power  to  the  relays  on  or  off. 
Table  2  on  page  15  shows  the  uses  of  the  pins  of  port  B,  for  this  purpose.  By  reading 
a  status  byte  from  Port  Bi  we  can  ascertain  the  position  of  each  relay.  Table  3  on  page 
16  shows  the  uses  of  the  pins  of  port  Bj  for  this  purpose. 

Let  us  designate  as  relay,  the  relay  controlled  by  pin  /  of  port  B,.lO  Valid  relays 
are  relays  through  relay^. 

There  is  no  relay-Q  since  bit  0  of  port  B,  has  a  special  purpose.  If  bit  0  of  Port 
Bi  is  a  1,  then  ehgible  relays  will  be  switched  on.  If  bit  0  of  Port  Bi  is  a  0,  then  ehgible 
relays  will  be  switched  off.  Placing  a  1  in  bit  /  of  Port  B,  makes  relay,  eligible  for 
switching.    Finding  a  1  in  bit  /  of  port  Bj  means  relay,  is  on. 

Once  we  have  issued  a  command  to  alter  the  position  of  one  of  the  relays,  we 
place  a  1  in  bit  4  of  port  C,  for  20  ms  to  permit  the  command  to  take  effect,  then  put  a 
0  in  that  bit. 


10  Note  that  pin  /  of  port  Bi  refers  to  the  same  relay  as  does  pin  /  of  port  Bj. 


III.     THE  .MATCHED  FILTER 

This  chapter  describes  the  design  of  a  filter  whose  purpose  is  to  detect  the  presence 
of  the  600  Hz  tone  characteristic  of  the  space  shuttle's  Auxiliar>-  Power  Unit  (APU). 
This  circuit  has  not  yet  been  built  and  tested,  but  the  most  critical  sub-circuit,  the 
bandpass  filter  it  uses,  has  been  simulated.  The  results  of  the  simulation  match  the 
predicted  performance  ver>-  closely  and  are  included  in  this  chapter. 

The  existence  of  the  tone  and  the  equation  of  a  fourth-order  elliptical  (Cauer) 
bandpass  filter  for  detecting  its  presence  are  documented  in  Jordan  [Ref  6].  While  the 
thrust  of  Jordan's  work  was  to  develop  a  digital  filter,  the  implementation  described  in 
this  thesis  u«;es  analog  electronics.  This  implementation  has  the  advantage  that  it  can 
be  constructed  e.xpeditiously  with  readily  available  components  and  requires  less  elec- 
trical power.  The  digital  implementation  described  by  Jordan  requires  special  hardware 
and  components.  In  particular,  the  Intel  292U  Digital  Signal  Processor  integrated  circuit 
he  proposed  to  use  is  no  longer  in  production.  Jordan  does  propose  an  analog  imple- 
mentation in  addition  to  the  digital  one.  It  requires  six  operational  amplifiers;  the  design 
proposed  here  requires  only  four,  and  so  require  less  power  to  operate.  This  is  important 
in  this  application,  since  power  is  limited. 

The  term  maiched  filter  ordinarily  refers  to  a  particular  kind  of  filter  based  on 
autocorrelation.  However,  the  term  has  come  to  be  apphed  incorrectly  to  the  bandpass 
filter  used  to  detect  the  application  of  power  to  the  Auxilian.-  Power  Unit.  Rather  than 
abandon  the  term  matched  filler,  which  has  become  thoroughly  entrenched  in  the  doc- 
umentation of  the  Vibro-acoustic  experiment,  this  author  will  continue  to  use  (misuse; 
it  to  denote  a  narrowband  filter  whose  purpose  is  to  respond  to  the  characteristic 
600  Hz  tone  emitted  by  the  space  shuttle's  Auxihan.'  Power  Units  beginning  about  five 
minutes  before  launch.  Figure  2  on  page  22  is  a  block  diagram  of  the  author's  proposed 
design  for  the  matched  filter. 

A.     MICROPHONE  INPUT  STAGE 

The  microphone  input  stage  is  shown  in  Figure  3  on  page  23.  It  uses  a  Panasonic 
\VM-063T  microphone.  A  620  Q.  resistor  limits  the  current  through  the  microphone  to 
8  rrtA.    The  output  is  an  AC  signal  superimposed  on  a  DC  bias. 
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Figure  2.      Block  diagram  of  the  Matched  Filter. 

B.     HIGH-PASS  FILTER 

Figure  4  on  page  24  shows  tlie  liigh-pass  filter  whicli  connects  the  microphone  to 
the  pre-amplifier.  Ihe  purpose  of  this  filter  is  to  eliminate  the  DC  bias  from  the  micro- 
phone signal.  While  simple  AC  coupling  can  in  principle  be  provided  by  a  capacitor 
alone,  a  resistor  to  ground  must  be  included  to  provide  a  path  for  DC  from  the  non- 
inverting  lead  of  the  pre-ampIifier.  F\en  though  the  input  bias  current  of  the  OPAlll 
operational  amplifier  used  to  implement  the  pre-amplifier  is  less  than  2  pA,  if  this  were 
neglected,  charge  would  accumulate  on  the  coupling  capacitor  and  the  amplifier  would 
saturate. 

The  cut-off  frequency  of  the  high-pass  filter  was  set  quite  low.  at 


fc- 


1 


1 


InRC       2;r(15U  KU)(150nF) 


=  7  Hz. 


(2) 


Since  the  signal  of  interest  is  well  above  this,  at/=  600  IIz,  the  filter  introduces  no  sig 
nificant  attenuation  or  phase  shift. 
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The  microphone  input  stnge. 


C.  PRE-AMPLiriER 

F'iguie  5  on  page  25  shows  the  pre-anipliCicr.  whicii  boosts  the  niicroplione  output 
voltage  by  a  factor  of  11  (21  dBj  using  a  non-inverting  configuration  of  the  OrA-111 
operational  aniplifier.  The  OI\\-lll  has  a  very  low  noise  of  less  than  40  nV/^,  Hz  at 
f=  1<")  IIz;  at  higher  frequencies  it  is  e\cn  lower.  'I  hus  the  microphone  input  is  boosted 
to  reasonable  levels  without  injecting  significant  noise  into  the  signal  and  is  bulfered 
prior  to  the  bahdpn';s  filter. 

D.  FOl'RTH-ORDER.  ELLIPTICAL  ((  AUER),  BANDPASS  FILTER 

Jordan  [Ref  6:  p.  45]  give^  an  analog  implementation  of  a  fourth-order,  elliptical 
(Cauer).  band-pass  filter.  The  design  provided  below  reduces  the  number  of  operational 
amplifiers  by  two,  from  six  to  four. 

The  coefficients  of  the  necessary  transfer  function  are  given  in  (Ref  6;  p.  36]  and  are: 


G{s)  =  -p 


s    +  2.9587  X  10  5'  +  1.8991  x  lo' 


2.4351  X  lo'i'  +  2.7642  x  lo'^^  +  3.3558  x  10^5  +  1. 8991  x  lO''* 


(3) 


1  he  author  used  a  computer  program  to  find  the  roots  of  this  transfer  function,  which 
can  be  rewritten  as  follows: 
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Figure  4.      High-pass  filter. 


G(s)  = 


(5  +J4A9  X  10  ){s  -74.49  X  10  )(5  +J3.0'!  x  10  |(t  -y3.07  x  10  ) 


(<r  +  62  4-73.84  x  10  ,)(j  +  62  -73. S4  x  10  )(5  +  58.8  4-73.59  x  10  )(s  4-58.8  -73.59  x  10  ) 


r-  (■^) 


By  multiplying  together  the  terms  containing  complex  conjugates  of  each  other,  we  ob- 
tain the  biquadratic  representation  of  this  function. 


5^ +  (3.068  X  loY 


s'.{^^^i^}.i>s.,.uCf 


^  +  (4.491  X  10  y 


.(iiil^j,,  (,,,.,., „y 


Each  of  the  factors  in  this  expression  has  been  written  in  the  form 

2  ,      2 


F{s)  - 


(5) 


(6) 


This  is  the  equation  of  a  notch  filter,  given  by  Ghausi  [Ref  12:  p.  16].  If  co,  =  to^,  then 
the  notch  filter  is  symmetric,  that  is,  the  attenuation  curve  to  the  left  and  right  of  the 
notch  frequency  is  symmetric  about  that  frequency  when  the  transfer  function  is  plotted 
on  a  logarithmic  frequency  scale.  The  first  factor  in  equation  (5)  has  a),  <  w^.  Conse- 
quently, this  factor  represents  a  high-pass  notch  filter.  I  he  magnitude  of  G{s)  rises  once 
oj  in  s=J<x>  exceeds  to,;  it  levels  off  once  oj  exceeds  co^.  By  contrast,  the  second  factor  in 
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Figure  5.       Pre-amplifier. 

eciuntion  (5)  ha?  oj,  >  w,.  Ihcrclore,  this  factor  represents  a  low-pass  notch  fiUer.  The 
magnitude  of  G(5)  drops  once  o  in  s  =j(.')  exceeds  w^:  it  levels  off' once  o)  exceeds  Oy  A 
low-pass  notch  filter  and  a  high-pass  notch  filter  placed  in  cascade  form  a  bandpass  filter 
if  suitable  choices  for  o,  and  o,  are  made  in  each  case. 

It  can  be  dillicult  to  implement  cascaded  filters  successfully.  However,  the  cascade 
filter  is  very  attractive  due  to  its  simplicity,  and  for  this  reason  ue  have  employed  it  here. 
The  design  presented  has  been  simulated  and  so  we  believe  it  would  be  quite  straight- 
forward to  implement  it  in  hardware. 

The  three  forms  of  notch  filter  and  the  bandpass  filter  formed  by  cascading  a  low- 
pass  and  a  high-pass  notch  filter  are  shown  in  Figure  9  on  page  29.  Three  of  these 
curves  were  calculated  by  computer  from  the  factors  in  the  transfer  function  given  in 
equation  (5).  The  symmetrical  notch  filter  transfer  function  plotted  in  the  figure  is  an 
example  of  what  results  from  equation  (6)  when  a)^  =  (o,.  It,  too,  was  calculated  by 
computer  from  the  transfer  function.  When  the  high-pass  notcii  filter  is  multiplied  by 
(put  in  cascade  with)  the  low-pass  notch  filter,  the  bandpass  filter  shown  in  the  figure 
results.  By  using  asymnielrical  notch  filters,  as  opposed  to  symmetrical  ones,  we  can 
obtain  high  gain  in  the  passband.  In  this  region  both  notcli  filters  have  Jiigh  gain  and 
so  reinforce  one  another. 
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Figure  6.      Magnitude  of  the  transfer  function  of  the  elliptical  bandpass  filter. 


Tlie  transfer  function  for  equation  (5)  is  plotted  separately  in  Figure  6  on  page  26; 
this  plot,  too,  was  generated  by  computer.  1  he  advantage  to  writing  the  equation  for 
the  elliptical  band-pass  filter  in  the  form  of  equation  (5)  is  that  it  is  a  comparatively 
simple  matter  to  implement  biquadratic  filter  sections  using  operational  amplifiers;  by 
cascading  these  sections,  the  entire  transfer  function  can  be  implemented.  Again,  it  can 
be  dillicult  to  implement  this  scheme. 

Figure  7  on  page  27  shows  a  schematic  for  a  generalized  biquadratic  filter  using  two 
operational  amplifiers.  The  blocks  labeled  with  the  letter  '"i"'  represent  admittances. 
The  design  equations  for  these  two  filter  sections  are  derived  in  APPFNDIX  A.  Deri- 
vation of  Design  Equations  for  the  Matched  Filter  on  page  71.  For  the  high-pass  notch 
filter,  they  are 
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Figure  7.       A  generalized  l)iquadratic  filter  using  two  opeiatioual  amplifiers. 


)-  =Q-Z,=-^ 


(7) 


} ,  =  sC^^Z, 


Y,  =  Q-Z,  = 


Y,  =  0<:>Z,  =  ex. 


y'7  =  sQ^Zj  -- 


sCi, 


''^  =  i^-'--Qr^ 


(8) 

(9) 

(10) 

(11) 

(12) 

(13) 
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Figure  9.  Notch  filters:  Synuiietric,  low-pass,  and  high-pass  notch  filters:  and  a 
bandpass  niter  formed  from  a  low-pass  and  a  high-pass  notch  filter  in 
cascade. 


t-4-(t)"] 


(14) 


For  the  high-pass  notch  filter,  co,  =  3.068  x  10\  co^  =  3.586  x  10^  ,  and  Q^  =  30.5.    Hence 

-^=8.176.  (16) 

If  we  make  the  arbitrary  choice  Q  =  10^  F,  then  we  get  C„  =  1.22  jiV  ,  R  =  27.9  Q, 
Z,  =  R,=  100  KQ,  Z,  =  ^,  =  818  KQ  ,  and  Q^R  =  851  Q..  Note  that  Z,  is  a  resistor 
whose  magnitude  in  ohms  is  the  reciprocal  of  the  magnitude  of  Q  in  farads.  Similarly, 
Z3  is  a  resistor  whose  magnitude  in  ohms  is  the  reciprocal  0^  the  magnitude  of  Q  in 
farads.  The  apparently  arbitrar\'  choice  for  Q  was  actually  not  random.  This  circuit 
must  be  made  with  components  whose  stability  is  high  to  minimize  changes  in  per- 
formance due  to  changes  in  temperature.  Capacitors  with  low  temperature  coefTicients 
are  available  in  polystyrene  up  to  values  of  10  ^F.  Using  this  value  for  Q  allows  R^  not 
to  be  too  big,  and  R  not  to  be  too  small. 

For  the  low-pass  notch  filter,  the  design  equations  are 

r,  =  y5  =  -^-z,  =  Z5  =  /?,  (17) 


1 

sC 


K 


(18) 
(19) 


Y,  =  0<^Z,  =  00  (20) 


Y,  =  -^oZ,  =  Q^R,  (21) 


*=4(t)'-'] 


(22) 


For  the  low-pass  notch  filter,  cj,  =  4.491  x  10' rads,  co^  =  3.843  x  10' rad  s,  and 
^,=  31.0.  So 

-^=11.35.  (24) 

If  we  arbitrarily  pick  R,  =  1  K^,  then  /?,  =  11.4  KQ,  C=  260  nF,  and  Q^R,  =  31  K  Q. 

Figure  8  on  page  28  shows  the  complete  bandpass  filter.  We  have  used  the  LF444  Quad 
Low  Power  JFET  Input  Operational  An^plifier.  It  has  an  extremely  low  input  bias  cur- 
rent of  50  pA  at  most,  and  only  35  nV/^  Mz  noise  voltage. 

We  simulated  the  frequency  response  of  this  filter  using  Micro-Cap  III  [Ref  13]. 11 
We  found  that  it  performed  almost  exactly  as  predicted.  Figure  10  on  page  32  is  a  plot 
generated  by  Micro-Cap  III  from  its  simulation.  By  comparing  this  plot  with  that  gen- 
erated from  the  transfer  function  in  Figure  6  on  page  26.  we  see  that  the  only  departure 
from  the  predicted  performance  is  a  sUght  asymmetr\'  in  the  ripple  in  the  passband. 
Since  we  are  concerned  only  with  detection  of  the  Au\iliar>'  Power  Units"  acoustic  sig- 
nature, and  not  with  faithful  reproduction,  this  is  not  a  matter  for  concern.  The  center 
of  the  passband  and  the  location  of  the  upper  and  lower  notch  frequencies  are  at  the 
predicted  frequencies.  The  gain  in  the  passband  also  is  as  predicted.  The  simulation 
results  are  strong  evidence  of  the  correctness  of  the  analysis  and  the  feasibility  of  the 
design. 

The  operational  amplifier  in  the  Pre-amplifier  is  an  OPAIIl.  Its  output  impedance 
is  100  Q.  The  input  impedance  of  the  bandpass  filter  is  well  above  10  kQ  throughout 
the  passband.  The  bandpass  filter  therefore  does  not  provide  a  significant  load  on  the 
Pre-amplifier,  and  so  the  simulation  results  can  be  considered  to  be  quite  accurate,  even 
though  they  were  produced  with  an  assumption  of  zero  output  impedance  from  the 
Pre-amplifier. 


1 1  In  the  simulation,  we  used  two  LF442  operational  amplifier  packages  instead  of  a  single 
LF444  operational  amplifier  package.  These  two  packages  provide  operational  amplifiers  with 
identical  electncal  characteristics,  which  justifies  the  substitution  made. 
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Figure  10.  Frequency  response  of  the  simulated  bandpass  filter:  This  plot  was 
obtained  using  Micro-Cap  111  [RcF.  13|.  The  phase  response  also  is 
shown.  It  is  the  curve  with  the  staircase-like  appearance.  Ihe  gain 
response  is  nearly  identical  with  that  generated  by  computer  and  shown 
in  Figure  6  on  page  26. 


E.  ADJUSTABLE  GAIN 

Figure  1 1  on  page  33  shows  how  a  single  LF4^4  operational  amplifier  is  configured 
as  a  non-inverting  amplifier  of  variable  voltage  gain  up  to  28  (29  dB).  The  gain  is  to  be 
adjusted  so  that  the  strongest  output  signal  has  3  V  peak-to-peak.  This  maximum  signal 
is  that  which  exists  when  the  Auxiliary  Power  Unit  outputs  its  characteristic  tone. 

F.  FULL-WAVE  RECTIFIER 

Figure  12  on  page  34  shows  the  design  of  a  full-wave  rectifier.  It  converts  the  600 
IIz  lone  admitted  by  the  band-pass  filter  into  a  fiuctuating  direct  current  signal.     This 
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Figure    11.       Aiiipliner  prn\iding  a  \aiial)le  >oltage  gain  up  to  28  =  28.9  dB. 


circuit  is  modified  from  an  absolute  value  circuit  provided  by  Jung  [Ref  14:  pp.  236-237]. 
It  operates  as  follows: 

1  he  in\erting  terniinai  of  both  operational  amplifiers  is  at  \irtual  ground.  There- 
fore, on  the  positive  cycle  of  the  incoming  signal,  current  passes  through  resistor  /?,  to 
the  inverting  input  of  the  fir-^t  operational  amplifier.  Ihis  current  is  unable  to  enter  the 
operational  amplifier  because  of  its  extremely  large  input  impedance:  nor  can  it  jiass 
through  diode  Dj  ,  since  that  diode  will  only  pass  current  in  the  other  direction.  Con- 
sequently, it  pa«;ses  through  resistor  /?,.  At  point  a.  the  voltage  is  the  negative  of  the 
input  voltage.  Ihe  same  amount  of  current  Hows  through  rcsi<;tor  Ry  Resistor  R^  has 
only  half  the  resistance  of  Z?,  ,  so  it  draws  twice  the  current  that  resistor  R^  can  supply. 
The  balance  comes  through  rcMstor  R^.  Thi";  causes  the  output  of  the  second  operational 
amplifier  to  match  that  of  the  input  to  the  circuit.  So  during  the  positive  cycle  of  the 
input,  the  input  voltage  is  duplicated  at  the  output. 

On  the  negative  cycle,  the  two  diodes  serve  to  keep  the  voltage  at  point  a  at  ground 
potential.  This  eliminates  all  current  through  resistors  /?,  and  R^ .  1  he  ellect  is  the  same 
as  if  the  first  operational  amplifier  were  removed  entirely.  The  second  operational  am- 
plifier is  then  in  the  usual  configuration  for  inverting.  Ihe  inverse  of  the  negative  input 
signal  is,  of  course,  a  positive  signal. 


F  U  L  L  -  W  A  V  E     RECTIFIER 
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Figure   12.      Full-nave  rectiiier. 

In  summary,  wliether  the  input  is  positive  or  negative,  the  output  is  the  absolute 
value  of  the  input. 

G.     LOW-PASS  FILTER 

The      signal      out      of     the      rectifier      has      a      fundamental      frequency      of 
2  X  600  IIz  =  1200  Hz  and  this  is  superimposed  on  a  DC  voltage  derived  as  follows: 


v(/)=  rsin(2n:/0 
=  rsin(co/) 


(25) 
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Figure    13.       A  general  secoiid-oider,  single  operational  amplifier,  low-pass  filter. 
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The  signal  into  the  filter  has  a  peak  amplitude  of  1.5  V.  Application  of  this  formula 
gives  r'^v- =0.955  V.  This  is  the  amplitude  of  the  strongest  signal  we  e.xpect  to  receive 
from  the  Auxilian.-  Power  Unit. 

The  low-pass  filter  which  follows  the  rectifier  is  designed  to  have  a  cut-off  frequency 
of/,  =  5  Hz.  This  frequency  is  well  below  the  fundamental  frequency  of  1200  Hz  passed 
by  the  rectifier.  As  a  consequence,  only  the  average  signal  V\y  we  have  just  derived  will 
be  present  at  the  output. 

The  circuit  is  based  on  the  general  circuit  shown  in  Figure  13  on  page  35.  The  de- 
sign equations  for  this  circuit  are  derived  in  APPENDIX  A.  Derivation  of  Design 
Equations  for  the  Matched  Filter  on  page  72  and  are  reproduced  here. 

Q=^C,Qp  (27) 

R,  =  R,  =  R= L=^  (28) 

Wpx  C,  C2 

In  this  application,  we  are  not  concerned  with  the  phase  of  the  signal.  Therefore  it  is 
reasonable  to  seek  a  maximally  flat  transfer  function.  To  do  this,  we  implement  a 
second-order  Butterworth  filter,  for  which 


Given  our  nominal  cut-ofT  frequency/  =  5  Hz,  we  arbitrarily  choose  Cj  =  220  nF.  We 
get  C,  =  440  nF,  and  R  =  102.3  kQ.  Since  the  cut-off  frequency  is  not  critical,  we  can 
pick  the  more  convenient  component  values  C,  =  470  nF  and  R  =  100  kQ.  The  resultant 
cut-off  frequency  is/  =  4.9  Hz  and  Qi,  =  0.731.  Since  the  purpose  of  this  low-pass  filter 
is  to  find  the  average  of  the  rectified  600  Hz  tone,  this  deviation  from  the  design  pa- 
rameters is  quite  acceptable  as  the  cut-off  frequency  still  is  well  below  the  fundamental 
frequency  of  1200  Hz  created  by  full-wave  rectification  of  the  600  Hz  tone. 

The  chief  benefit  provided  by  this  filter  is  a  roll-off  of  40  dB/decade  when 
/>/  =  4.9  Hz.  This  amounts  to  96  dB  attenuation  when/=  1200  Hz,  which  is  ample 
to  suppress  the  AC  component  in  the  signal  out  of  the  full-wave  rectifier.  Figure  14  on 
page  36  shows  the  component  choices  and  circuit  for  the  second-order  low-pass  filter. 
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Figure   15.      Threshold  detector. 

H.     THRESHOLD  DETECTOR 

Figure  15  on  page  38  shows  the  design  of  a  thresiiold  detector.  There  is  some  evi- 
dence that  other  sources  of  600  IIz  signals  that  migiU  be  present  simultaneously  will  be 
15  dB  below  this.  The  voltage  whicii  is  15  dl)  below  0.955  V  is  0.170  V.  Any  signal 
which  exceeds  the  0.170  V  threshold  just  derived  should  cause  the  threshold  detector  to 
signal  that  a  sufficiently  strong  600  Hz  signal  is  present.  Presumably  this  signal  is  from 
the  Auxiliary  Power  Unit.  Ihe  threshold  detector  uses  an  LM358  operational  amplillcr. 
This  device  requires  only  a  single  power  supply  and  it  tends  not  to  "latch  up"  when 
configured  as  a  comparator.  Its  output  goes  high  (to  5  V)  whenever  the  threshold  is 
exceeded.   Otherwise,  its  output  is  held  low  (at  ground). 

I.     RESETTABLE  PULSE  COUNTER 

Figure  16  on  page  39  shows  the  Resettable  Pulse  Counter.  Its  purpose  is  to  signal 
the  presence  of  a  600  Hz  signal  from  the  Auxiliary  Power  Unit  if  it  has  been  contin- 
uously present  for  73.1s.  Spurious  signals  with  a  component  at  f  =  600  Hz  may  be 
present  intermittently.  We  do  not  expect  them  to  be  continuously  present  at  levels  more 
than  15  dB  below  that  of  the  strongest  signal  expected  from  the  Auxiliary  Power  Unit. 
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Consequently,  the  Resettable  Puke  Counter  has  the  efl'ect  of  eliminating  false  triggering 
due  to  these  spurious  signak. 

Wlienever  the  threshold  detector  indicates  the  presence  of  the  6U0  Ilz  tone  charac- 
teristic of  the  Auxiliary  Power  Unit,  it  produces  a  high  output.  I  his  signal  is  applied  to 
llie  LOAD(L)  input  of  the  Resettable  Pulse  Counter.  Ihis  permits  the  counter  to  begin 
marking  off  the  pulses  which  arrive  from  the  Pulse  Generator,  described  below.  Because 
the  pre-load  inputs  //  through  D  all  are  connected  to  ground,  the  counter  will  count  from 
zero  to  15.  at  which  point  its  CO  output  will  go  high.  '1  hus.  the  counter  \\'\\\  permit 
sixteen  pulses  to  arrive  from  the  Pulse  Generator  before  it  goes  high.  Since  the  pciiod 
of  these  pulses  is  r=  4.57  5,  the  output  will  go  high  if  14  x  4.57  5=  73.1  5  elapses. 
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Figure   17.      Astable  operation  of  the  LM555  Timer  to  generate  a  pulse  train. 

J.     PULSE  GENERATOR 

This  ttiodule  is  based  on  the  LM555  Tinier  integrated  circuit.  The  data  sheet  for  thi<; 
circuit  provides  equations  to  permit  choo<;ing  component  values  to  provide  the  desired 
period  and  duty  cycle.  The  duty  cycle  is  not  critical  to  this  apj->lication.  Figure  17  on 
page  40  shows  the  general  configuration  for  astable  operation,  which  is  the  mode  of 
operation  which  produces  a  periodic  signal.    I  he  design  etjuations  arc: 


lcHarge  =  0.69}{R^  +  R,)C 


(30) 


W;,..g.  =  0.693y?flC. 


(31) 


Thus  the  total  period 


T==  t,,,,g,  +  t,,,,,,,^,  =  0.693(/?^  +  2/?5)C 


(32) 
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Sol'. ins  for  C  \vc  eet 


C  = 


0.69HR,  +  2Rn)C 


\\  ^^ 


(33) 


and  tlie  dutv  cvcle 


D  = 


R. 


R,  -  2R, 


(3-lj 


Picking  R^  =  R,=  200  Ki2  provides  a  duty  cycle  D  =  0.333  ,  which  is  perfectly  accepta- 
ble for  this  non-critical  parameter. 

Figure  18  shows  a  Pulse  Generator  based  on  this  configuration.  This  circuit 
produces  a  regular  stream  of  square  pulses  of  period  7  =  4.57  s.  These  are  used  by  the 
Resettable  Pulse  Counter  to  measure  the  amount  of  time  when  a  reasonably  strong  6<)<) 
Hz  signal  is  present. 


K.    SUMMARY 

This  completes  the  description  of  the  somewhat  inappropriately  named  matched  fil- 
ter. Simulation  of  the  bandpass  filter  used  in  the  matched  filter  has  shown  that  that  part 
of  the  design  is  correct  and  feasible.  The  implementation  and  testing  of  the  bandpass 
filter  and  the  other  components  of  the  entire  circuit  remain  to  be  done  in  the  future. 


IV.     DESIGN  OF  THE  CONTROL  SOFTWARE 

In  describing  the  software  which  operates  the  controller  hardware,  we  shall  adopt 
the  following  conventions. 

We  will  show  variable  names  in  bold,  e.g.,  variable;  function  names  in  bold  with 
(possibly  empty)  parentheses  at  the  end, 12  e.g.,  functionQ,  and  constants  in  uppercase, 
e.g.,  CONSTANT.  13  We  shall  also  use  bold  for  the  names  of  regions,  described  below  in 
Section  A.  Memon.'  Map.  Development  of  the  software  for  the  Vibro-acoustic  Exper- 
iment was  done  under  the  Microsoft  Disk  Operating  System  (MS  DOS).  Figure  35  on 
page  S9  shows  how  we  arranged  the  hierarchy  of  files  containing  the  source  code,  object 
code,  header  files,  eic.  See  APPENDIX  D.  HIER,\RCH1CAL  ORGANIZATION 
OF  SOFTWARE  FILES  on  page  SS  for  a  more  complete  discussion  of  this  organiza- 
tion. 

A.     MEMORY  MAP 

Figure  19  on  page  44  shows  the  addresses  of  the  ROM  and  R.-WI  in  the  computer. 
Our  NSCSOO-based  controller  provides  for  up  to  eight  EPROMs  and  RAMs  in  any 
combination,  each  holding  8  KBytes.  The  wiring  oi'  the  printed  circuit  board  permits 
placing  a  RAM  chip  in  any  of  the  addresses  evenly  divisible  by  (J\2u<)0  {e.g.,  OxOOOO, 
0x2000.  0x4000.  e[c.)  The  addition  of  a  jumper  wire  permits  the  R.AM  chip  to  be  re- 
placed by  an  EPROM. 

The  NSCSOO  uses  the  same  architecture  as  the  Z-80  [Ref  10].  Because  the  Z-80 
architecture  causes  execution  to  begin  at  address  0x0000  whenever  power  is  apphed,  it 
is  necessar>-  to  install  an  EPROM  at  location  0x0000.  It  was  therefore  convenient  for 
us  to  put  all  EPRO.Ms  at  the  low  end  of  memor\-,  and  all  R.-WIs  at  the  high  end.  AP- 
PENDIX C.  HOW  THE  UNIWARE  SOFTWARE  USES  THE  COMPUTER 
MEMORY'  on  page  86  explains  the  way  in  which  the  Uniware  C  Compiler  employs  the 
memory-. 


12  According  to  custom  in  the  C  programming  language. 

13  In  C.  constants  are  declared  using  the  #define  directive.  These  are  stored  in  various  header 
files  such  as  vibro.h. 
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Figure  19.  Memory  ninp  of  the  computer:  Ihis  figure  shows  tlie  locations  of 
ROVI,  RAM,  and  the  eight  software  regions.  I  he  ROM  and  Ry\M 
addresses  are  specified  by  the  hardware  design.  1  he  addresses  of  the 
regions  are  specified  by  the  Hnker. 


B.     OPERATION  OF  THE  MBRO-ACOLSTIC  EXPERIMENT 

1.     Menu-driven  Diagnostic  Program 

Some  years  ago  the  film  Alien  was  produced.  As  a  part  of  the  publicity  cam- 
paign attending  its  release  was  the  slogan.  "In  space,  no  one  can  hear  you  scream." 
Similarly,  when  the  Vibro-acoustic  Experiment  is  performed  in  the  Space  Shuttle,  there 
will  be  no  one  to  hear  it  scream,  that  is,  to  monitor  the  progress  of  the  experiment. 

This  is  quite  different  from  the  situation  on  the  ground,  where  generally  there 
is  a  monitor  attached,  and  there  is  someone  monitoring  execution  of  the  program. 
Furthermore,  there  is  a  need  on  the  ground  to  test  components  of  the  experimental 
package  without  running  the  experiment  from  start  to  finish.  For  example,  we  have 
found  it  helpful  to  be  able  to  operate  the  bubble  memory  module  attached  to  the  con- 
troller hardware  in  a  manual  mode.  By  this  means,  we  have  debugged  the  software  and 
ensured  that  it  can  operate  the  bubble  memory  successfully  before  attempting  to  use  it 
in  our  application. 

An  obvious  way  to  allow  software  to  be  tested  on  the  ground  but  used  to  run 
the  experiment  in  space  would  be  to  compile  a  different  program  for  each  purpose.  This 
IS.  to  put  it  mildly,  a  ver>'  inconvenient  approach.  Not  only  must  two  distinct  programs 
be  managed,  but  assurance  that  the  diagnostic  version  works  gives  little  assurance  that 
the  operational  one  will  work.  We  have  elected  to  have  a  single  program,  usable  under 
all  circumstances.  This  requires  that  the  program  be  able  to  recognize  that  someone  is 
monitoring  it.  To  do  tins,  it  simply  checks  bit  3  of  port  C,  to  see  if  a  terminal  is  con- 
nected to  the  RS-232C  serial  interface.  (See  Table  6  on  page  18.)  If  there  is  no  terminal 
attached,  the  program  assumes  that  there  is  no  one  r.  :iitoring  execution,  i.e..  the  ex- 
perimental package  might  ven.'  well  be  in  space,  and  so  the  experiment  should  be  oper- 
ated. If  there  is  a  terminal  attached,  then  the  package  cannot  possibly  be  in  space,  since 
we  don't  intend  to  include  a  monitor  in  the  Space  Shuttle.  In  this  case,  the  control 
program  does  not  operate  the  experiment.  Instead,  it  presents  to  the  operator  a  series 
of  menus  of  choices  from  which  the  operator  can  choose  which  part  of  the  system  to 
exercise. 

The  menu  subsystem  provides  the  following  capabilities: 

1.  SoftAvare  reset.    This  has  an  effect  similar  to  that  caused  by  removing  power  and 
then  applying  it  again. 

2.  Real-time  clock  control.    The  user  can  set  the  date  and  time,  read  them,  or  test  a 
time-out  feature  used  to  synchronize  events  during  the  experiment. 


3.  Pover  subsystem  control.  Individual  subsystems  can  be  powered  up  or  down  under 
the  user's  control. 

4.  Bubble  memory  control.  The  bubble  memory  used  for  storing  a  log  of  events  per- 
formed during  the  experiment  can  be  powered  up  or  down,  mitialized,  or  tested 
under  the  user's  control.  These  tests  are  at  a  very  low  level.  Data  stored  in  the 
bubble  memor\'  consists  of  character  strings,  and  these  are  unformatted.  The  data 
are  not  treated  as  formatted  log  entries. 14 

5.  Analog-to-Digital  (A/D)  converter  control.  Any  of  the  temperatures  and  voltages 
accessible  through  a  channel  of  the  on-board  AD  converter  can  be  read  under  the 
user's  control. 

6.  Running  the  experiment.  This  causes  the  Vibro-acoustic  experiment  to  be  per- 
formed. The  only  difference  between  operating  the  experiment  under  menu  control 
and  operating  it  with  no  terminal  attached  is  that  wiih  a  terminal,  a  large  amount 
of  diagnostic  information  is  displayed  during  execution.  IViihoui  a  terminal  at- 
tached, this  information  is  lost.  The  advantage  to  this  approach  is  that  if  the  ex- 
periment works  on  the  ground,  we  are  assured  it  will  work  in  space,  since  essentially 
the  same  code  is  executed  in  both  cases. 

7.  Perform  port  input  and  output.  This  is  a  very  low-level  test.  Characters  of  data  can 
be  written  to  or  read  from  a  port  at  any  address,  one  at  a  time.  This  is  helpful  in 
debugging  the  software. 

8.  Display  contents  of  the  controller's  memor}.  This,  too,  is  a  ver\  low-level  routine 
useful  only  for  debugging. 

9.  E.xamine  or  change  bubble  memor>'.  These  routines  permit  the  formatted  contents 
of  the  bubble  memory  log  to  be  displayed  in  a  readable  manner  on  the  terminal. 
In  addition  to  allowing  debugging  to  be  done,  this  operation  permits  the 
experiment's  operation  to  be  tailored  in  advance. 

Each  of  these  menu  items  leads  to  a  further  menu  of  functions  to  permit  the 
operator  to  test  all  subsystems  of  the  experiment.  These  routines  are  discussed  in  detail 
in  the  software  description  contained  in  Section  A.  Major  Subroutines  and  Functions 
on  page  108. 

2.     Performing  the  Experiment 

This  section  describes  in  detail  the  steps  of  the  experiment.    These  steps  are  il- 
lustrated in  the  flowcharts  contained  in  the  following  pages. 
a.     Microprocessor  Control  Program 

Flowchart  0  in  Figure  20  on  page  48  shows  the  overall  structure  of  the 
control  program.  The  program  begins  executing  when  power  is  first  appUed  to  the  sys- 
tem. After  initializing  the  hardware  for  proper  operation,  it  checks  to  see  whether  or 
not  there  is  a  terminal  attached.   If  not,  it  proceeds  on  the  footing  that  it  should  run  the 


14  There  are  additional  bubble  memories  within  the  Solid  State  Data  Recorder  (SSDR)  which 
are  not  tested  by  these  routines. 


experimeni.  bypassing  all  the  menu  routines.  If,  on  the  other  hand,  a  terminal  is  con- 
nected, then  the  program  deduces  that  the  experiment  is  not  being  run  in  space,  where 
no  terminal  uill  be  available,  and  so  it  enters  the  menu  subsystem.  The  experiment  is 
not  performed  unless  the  user  specifically  requests  this  later. 

b.  Initialize  Hardware 

Flowchart  1  in  Figure  21  on  page  49  is  a  more  detailed  look  at  block  1  of 
Flowchart  0  in  Figure  20  on  page  48.  The  first  initialization  task  to  be  performed  is  to 
let  the  programmable  input  output  devices  know  which  data  lines  are  for  input  and 
which  are  for  output.  There  are  two  clocks  which  also  must  be  initialized.  One  of  these 
provides  a  clock  signal  for  serial  communications  at  9600  baud.  The  other  provides  a 
clock  for  conversion  of  data  from  analog  to  digital  form. 

c.  Run  the  Vibro-acoustic  Experiment 

Flowchart  2  is  shown  in  Figure  22  on  page  50.  It  is  a  more  detailed  look 
at  block  2  o'l  Flowchart  0  m  Figure  20  on  page  4S. 

One  of  Its  first  tasks  is  to  initialize  certain  variables  in  the  software.  It  then 
ascertains  (by  consulting  a  record  in  the  bubble  memory)  whether  the  full  experiment 
or  the  abridged  version  is  to  be  performed.  The  full  experiment  consists  of  the  sw^ep. 
scroll,  launch,  and  posi-launch  phases  already  described  in  Chapter  I.  INTRODLC- 
TION  on  page  1.  The  scroll  phase  is  omitted  if  the  Auxiliary  Power  Units  (APL's)  are 
not  detected  before  the  launch  was  detected. 

In  the  abridged  experiment,  the  program  initially  checks  to  see  if  the 
barometric  switches  have  been  triggered,  which  they  would  have  been  were  the  Space 
Shuttle  already  in  space.  This  check  is  done  to  avoid  entering  record  phase  a  second 
time  when  the  space  shuttle  is  already  aloft.  Such  a  situation  might  arise  after  a  power 
fault  during  lift-off:  to  recommence  record  mode  would  erase  the  acoustic  data  recorded 
during  the  launch. 

The  next  decision  to  be  made  is  whether  or  not  to  enter  record  mode. 
Conceivably,  the  .Auxiliary  Power  Units  could  be  detected  and  the  record  phase  entered 
at  some  point,  but  the  launch  might  then  be  scrubbed.  If  power  were  not  removed  from 
the  experiment,  then  the  control  fiow  would  permit  record  mode  to  be  commenced  anew. 
Why  not  just  stan  record  mode  again?  Operating  the  Solid  Slate  Data  Recorder  with 
its  bubble  memories  consumes  considerable  power.  We  cannot  afford  to  waste  that 
power  by,  in  effect,  continuously  operating  the  recorder  unnecessarily.  The  decision  not 
to  let  this  mode  be  begun  again  until  at  least  12  hours  after  the  last  time  will  prevent  this 
from  happening.   .Also,  if  a  power  fault  occurred  after  the  record  phase  began,  we  would 
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prefer  to  avoid  interfering  with  the  Solid  State  Data  Recorder  (SSDR).  which  might  still 
be  operating  successfully  in  rccoid  mode.  This  safeguard  will  ensure  that  such  interfer- 
ence does  not  occur.  If  a  mission  is  sciubbcd,  it  would  not  be  rescheduled  lor  at  least 
24  hours.  The  12  hour  wait  is  long  enough  to  avoid  interfering  unduly  with  the  SSDR 
and  to  preclude  wasting  power  and  is  short  enough  to  permit  correct  operation  w  hen  the 
launch  is  rescheduled. 

Once  either  the  Au.xiliary  Power  Units  or  any  launch  indication  are  de- 
tected, record  mode  can  be  entered.    Normally,  upon  completion,  we  expect  to  be  in 
space.     In  this  case,  control  will  be  passed  to  the  post-launch  phase  of  the  mission. 
Otherwise,  the  mission  must  have  been  aborted  and  the  12  hour  wait  begins. 
d.     Initialize  Software 

Flowchart  2.1  in  Figure  23  on  page  51  is  a  more  detailed  look  at  block  2.1 
of  Flowchart  2  in  Figure  22  on  page  50.  Initializing  the  software  entails  discovering 
what  tlie  current  status  of  the  experiment  is.  For  example,  this  might  be  the  first  time 
power  has  been  applied,  in  which  case  the  sweep  phase  has  not  been  performed  yet,  and 
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Figure  21.       ri()\>cliait  1:     The  flowchart  shows  the  initialization  of  liarduare  and 
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the  launch  has  not  taken  place.  Or  perhaps  the  sweep  was  performed  previously,  but  the 
Space  Shuttle  still  is  on  the  ground.  'I  his  information  uas  stored  previously  in  the 
bubble  memory  log,  and  it  must  be  retrieved  before  the  controller  can  know  what  it 
should  do. 

The  controller  also  turns  off  the  Voltage  Controlled  Oscillator  for  safety 
reasons.  Because  the  speaker  connected  to  it  emits  such  a  loud  tone,  it  would  be  dan- 
gerous to  allow  it  to  operate  until  the  controller  can  first  sec  whether  it  has  been  begun 
once  before.  If  NASA  eventually  agrees  to  permit  the  sneep  phase  to  be  performed,  they 
will  almost  certainly  afTord  us  only  one  opportunity  to  perform  it.  If  it  does  not  com- 
plete successfully,  there  is  no  second  chance.  1  he  heater  subsystem  also  is  deactivated 
as  a  power-saving  measure  until  the  controller  can  find  out  exactly  what  to  do. 
e.     Do  Sneep 

Flowchart  2.2  in  Figure  24  on  page  52  is  a  more  detailed  look  at  block  2.2 
of  Flowchart  2  in  Figure  22  on  page  50.  If  the  sneep  phase  ever  was  started  before,  or 
if  the  launch  was  performed  previously,  the  sweep  phase  is  skipped.  Otherwise  the  con- 
troller notes  in  the  bubble  memory  log  that  it  has  now  staited  the  sweep  phase,  which 
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\m11  ensure  tliat  it  never  tries  to  restart  it.     1  lic  controller  now  cau<;es  echoes  of  known 
IVcqucncies  to  be  recorded. 

The  controller  expects  to  be  infoinied  of  the  completion  of  the  sweep  phase. 
Ilouevcr.  a  13  minute  timeout  is  initiated  to  make  sure  that  the  controller  does  not  wait 
forever  for  tin<;  information. 

f.  SlaH  Rccon/iiti;  Response  at  Kiionn  ricqiiencies 

Flowchart  2.2.2  in  Figure  25  on  page  53  is  a  more  detailed  look  at  block 
2.2.2  of  Flowchart  2.2  in  I'igure  24  on  page  52.  It  shows  the  step*;  entailed  in  initiating 
the  sweep  phase.  1  he  Analog  to  Digital  Comcrter  Subsystem  must  be  turned  on  first, 
since  the  converters  power  the  microphones  which  recci\e  the  acoustic  signal.  1  he 
Voltage  Controlled  Oscillator  (VCO)  can  then  be  started,  followed  by  the  Solid  State 
Data  Recorder  (SSDR).  Starting  the  SSDR  requires  first  applying  power  to  it  and  then 
commanding  it  to  enter  sweep  mode. 

g.  Stop  Recording  Response  at  Known  Frequencies 

Flowchart  2.2.4  in  Figure  26  on  page  54  is  a  more  detailed  look  at  block 
2.2.4  of  Flowchart  2.2  in  Figure  24  on  page  52.  It  shows  the  steps  entailed  in  termi- 
nating the  sweep  phase.  1  hese  steps  are  to  remove  power  from  three  subsystems:  the 
Voltage  Controlled  Oscillator  (VCOj,  the  Solid  State  Data  Recorder  (SSDR)  and  the 
Analog  to  Digital  (A  D)  Con\erter. 


Figure  24.      Flowchart  2.2:     This  flowchart  shous  the  steps  entailed  in  performing 
the  sweep  phase  of  the  experiment. 
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Figure  25.  Floucliart  2.2.2:  Ihis  Ilowchart  shows  the  steps  entailed  in  initiating 
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periment. 


h.      iVait  for  APIs  to  Stmt  or  for  Launch  Indications 

Flowchart  2.3  in  Figure  27  on  page  55  is  a  more  detailed  look  at  block  2.3 
of  F'loucliart  2  in  Figure  22  on  page  50.  I  here  are  two  pos<;ible  indications  of  a  launch. 
One  is  a  signal  from  the  Vibration-activated  Launch  Detector  circuit.  I  he  other  is  a 
signal  from  the  barometric  switches.  If  either  of  these  is  present,  the  flag  LAUNCHED 
is  asserted.  Otherwise,  the  controller  will  check  to  see  if  the  Auxiliary  Power  Units 
(APLs)  have  been  detected.  If  so,  the  Hag  APUs  ON  is  asserted.  If  no  indications  are 
present,  the  controller  will  continue  looking  for  them  indefinitely. 
/.     Do  Scroll 

Flowchart  2.4  in  Figure  28  on  page  56  is  a  more  detailed  look  at  block  2.4 
of  Flowchart  2  in  Figure  22  on  page  50.    It  shows  the  steps  entailed  in  performing  the 
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scroll  pliase.    Power  is  applied  to  the  Solid  State  Data  Recorder  (SSl)R),  and  it  is  then 
commanded  to  enter  scroll  mode. 

Ihe  mission  will  be  scrubbed  if  no  launch  occurs  within  seven  minutes  after 
the  Auxiliary  Power  Units  are  started.    We  initiate  a  ten  minute  timeout,  which  is  con- 
servative.   If  at  the  end  often  minutes  no  launch  indications  have  been  detected,  the 
program  aborts;  otherwise,  it  asserts  the  LAUNCHED  Hag. 
j.     Abort 

Flowchart  2.4.4  in  Figure  29  on  page  57  is  a  more  detailed  look  at  block 
2.4.4  of  Flowchart  2.4  in  I'igure  28  on  page  56.     It  shows  that  when  the  mission  is 
deemed  to  have  been  aborted,  power  is  removed  from  all  subsystems. 
k.     Do  Launch 

Flowchart  2.5  in  Figure  30  on  page  58  is  a  more  detailed  look  at  block  2.5 
of  Flowchart  2  in  Figure  22  on  page  50.  The  flowchart  shows  the  steps  entailed  in 
performing  the  launch  phase  of  the  experiment.    The  first  step  is  to  determine  whether 
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Figure  2'.  FIo\^cllart  2.3:  This  flowchart  shows  the  steps  entailed  in  Hstening  for 
the  Auxihan.-  Power  Units  (AI'Us)  while  simultaneously  waiting  for  in- 
dications of  a  launch. 


this  is  necessary-  or  not.  if  the  launch  was  ever  determined  to  have  been  completed  in 
the  past,  the  LAl'NCH  DO.N'E  will  have  been  asserted  then,  in  this  case,  it  is  not  ap- 
propriate to  perform  this  phase  a  second  time  and  so  all  the  blocks  in  this  flowchart  will 
be  skipped.  Otherwise,  the  Solid  State  Data  Recorder  (SSDR)  is  conunanded  to  leave 
scroll  mode  and  enter  launch  mode.  Within  two  minutes  of  the  time  of  launch,  there  will 
no  longer  be  any  air  in  the  Space  Shuttle's  cargo  bay.  We  initiate  a  three  minute  timeout 
so  that,  in  the  event  that  the  SSDR  fails  to  signal  completion  of  the  launch  phase,  the 
controller  will  not  be  stuck  permanently  in  launch  mode.  1  he  controller  repeatedly 
checks  either  for  a  completion  signal  from  the  SSDR  or  lor  a  timeout. 
/.     Check  for  a  Completed  Launch 

Flowchart  2.5.3  in  Figure  31  on  page  59  is  a  more  detailed  look  at  block 
2.5.3  of  Flowchart  2.5  in  Figure  30  on  page  58.    If  the  L.Al'NCH  DONE  (lag  ever  was 


Figure  28.  Flowchart  2.4:  1  his  llouchart  shows  the  steps  entailed  in  performing 
the  scroll  phase  between  the  time  tlie  AuxiHary  Power  Units  (A PL's) 
start  operating  and  the  time  that  the  launch  is  detected. 


asserted,  this  block  does  nothing.  However,  if  this  flag  was  not  previously  asserted,  the 
state  of  the  barometric  pressure  switches  is  checked.  If  cither  of  them  has  tripped,  we 
have  a  positive  indication  of  launch.  It  is  then  appropriate  to  set  the  LAUNCH  DONE 
nag. 
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Figure  29.       Flo\> chart  2. 4. -4:      This  flowcliart  slious  wluit  liappens  when  an  abort 
condition  is  detected. 


m.     Do  Post-launch 

Flowcliart  2.6  in  figure  32  on  page  6'.)  is  a  more  detailed  look  at  block  2.6 
of  riowciiart  2  in  Figure  22  on  page  5(i.  It  shows  the  -^tcps  entailed  in  perlonning 
post-launch  functions.  1  he^e  are  the  monitoring  (unctions  required  after  the  Sjvicc 
Shuttle  has  left  the  earth's  atnio-^phere.  1  he  (ir'^t  step  is  to  rcnio\e  power  from  all  ■sub- 
systems. A  five  nunute  timeout  is  then  initiated.  The  cdcct  of  this  is  to  permit  system 
status  to  be  recorded  e\ery  li\e  minutes.  1  he  heater  subs\stem  is  one  of  the  subsystems 
which  needs  monitoring.  A  check  is  done  to  ensure  that  the  launch  has  been  recorded 
as  complete.  These  two  steps  are  repeated  continually  throughout  each  li\e  minute  pe- 
riod. At  the -completion  of  that  period,  current  valuc<;  of  the  temperature  and  \oltage 
at  various  points  are  read  and  stored  in  the  bubble  memoiy  log.  A  check  aho  i<;  made 
to  see  if  the  voltages  on  the  bu<;es  are  too  low.  If  so.  the  po<;t-lainich  processing  cea<;es. 
n.     Monitor  Healer  Subsystem  Operation 

Floucharl  2.6.3  in  Figure  33  on  page  61  is  a  more  detailed  look  at  block 
2.6.3  of  Flowchart  2.6  in  Figure  }2  on  page  60.  It  has  two  branches.  In  one.  tlie  tem- 
perature of  the  experimental  apparatus  is  suflicienlly  high,  in  which  case  the  heater 
subsystem  is  deactivated.  In  the  other  branch,  the  temperature  is  too  low  and  the  heater 
subsystem  is  activated. 
0.     Do  Record 

Flowchart  2.7  in  Figure  34  on  page  62  is  a  more  detailed  look  at  block  2.7 
of  I  lowchart  2  in  Figure  22  on  page  50.  It  shows  the  steps  entailed  in  putting  the  e.K- 
pernnent  into  the  record  phase.     1  hese  steps  are,  first,  to  put  the  Solid  State  Data  Re- 
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Figure  30.      Flowchart  2.5:      1  his  flowchart  sliows  the  steps  entailed  in  performing 
the  launch  phase  of  the  experiment. 


corder  (SSDR)  into  the  launch  mode,  and  then  to  begin  a  20  minute  timeout,  after  which 
time  the  SSDR  would  have  run  out  of  memory  in  which  to  store  recorded  sound.  The 
SSDR  normally  would  inform  the  controller  that  it  has  completed  operation  before  the 
timeout  occurs.  The  timeout  is  meant  to  permit  the  controller  to  leave  the  record  phase 
even  if  the  SSDR  fails  to  signal  completion. 


Figure  31.  Flowchart  2.5.3:  This  flowchart  sliows  tlie  steps  entailed  in  deciding 
whether  or  not  a  launch  has  occurred.  The  barometric  switch  is 
deemed  to  be  the  most  reliable  (and  only  convincing)  indication  of  a 
launch. 


Figure  32.  Flowchart  2.6:  This  flowchart  shows  the  steps  entailed  in  performing 
measurements  and  monitoring  temperatures  and  voltages  after  the  ex- 
periment is  complete. 
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Figure  34.       Flowchart  2.7:     This  flowchart  shows  the  steps  entailed  in  performing 
the  record  phase  of  the  abridged  experiment. 


V.     HOW  TO  GET  THE  EXPERIMENT  READY  FOR  A  LAUNCH 

This  chapter  explains  what  must  be  done  prior  to  the  launch  of  the  Space  Shuttle 
to  ensure  that  the  experiment  is  performed  correctly.  The  current  status  of  the  exper- 
iment is  stored  in  page  0  of  the  bubble  memory-  log.  By  setting  appropriate  information 
there,  we  can  ensure  that  when  power  next  is  applied  to  the  experimental  apparatus,  the 
correct  sequence  of  steps  is  performed. 

There  are  really  two  possible  experiments  to  be  performed:  the  unabridged  exper- 
iment and  the  abridged  one.  The  abridged  experiment  dispenses  with  the  sweep,  scroll, 
and  Uiunch  phases  of  the  experiment,  replacing  them  with  a  single  record  phase.  Which 
of  these  is  to  be  run  must  be  stored  in  page  0  before  launch. 

A.     L  N.ABRIDGED  EXPERIMENT 

Attach  a  terminal  to  the  RS-232C  interface  and  apply  power  to  the  experiment.  The 
controller  will  present  the  following  menu  on  the  terminal. 

A  Software   reset. 

B  Realtime   clock   functions. 

C  Power   relay  switching   functions. 

D  Bubble   memory   test    functions. 

E  A/D   converter   functions. 

F  Run   experiment. 

G  Perform  port    I/O. 

H  Display  contents   of   controller  memory. 

I  Examine  or  change  the  data   logged   in  the  bubble  memory. 

Z  Exit  this   menu. 

Choose  option  (I).   The  following  menu  will  be  presented  next. 

A  Display  page  0. 

B  Display  a  page  of  the    log. 

C  Alter  the  contents   of  page  0. 

Z  Exit   this   menu. 

Choose  option  (C).   The  following  menu  will  next  be  displayed. 


A  Toggle  'sweepstarted'  flag  from  TRUE  to  FALSE. 

B  Toggle  'launchdone'    flag  from  TRUE  to  FALSE. 

C  Alter  value  of  next  available  page  from  0x12  =  18. 

D  Alter  value  of  next  available  half  page  from  1  to  0. 

E  Toggle  'full_experiment'  flag  from  TRUE  to  FALSE. 

F  Specify  the  'RECORD_start_time'  (make  this  at  least  12  hours  before  the 

present  to  permit  RECORD  mode  to  be  initiated. ) 

Z  Exit  this  menu. 

The  menu  may  not  look  exactly  like  this,  inasmuch  as  the  flags  and  page  numbers  may 
van'.  The  objective,  however,  is  to  set  the  sweepstarted  flag  to  FALSE;  the  launchdone 
flag  to  FALSE;  the  value  of  the  next  available  page  to  1;  the  value  of  the  next  available 
half-page  to  0;  the  value  of  the  full_e\periment  flag  to  TRUE.  The  value  of  the 
RECORD_start_tinie  does  not  matter  since  the  record  phase  is  not  performed  in  the 
unabridged  experiment.  If  a  value  is  already  correct,  it  may  be  left  alone.  Only  if  it 
needs  to  be  changed  must  the  corresponding  menu  choice  be  made. 

B.  ABRIDGED  EXPERIMENT 

For  the  abridged  experiment,  follow  the  same  steps  as  with  the  full  experiment  with 
the  following  differences.  The  full_experiment  flag  should  be  set  to  FALSE,  and  the 
RECORD_start_time  should  be  set  to  some  value  at  least  12  hours  before  launch.  The 
value  of  the  sneepstarted  flag  does  not  matter  because  the  sweep  phase  is  omitted  in  the 
abridged  experiment. 

C.  BOTH  VERSIONS  OF  THE  EXPERIMENT 

Once  all  the  required  choices  have  been  made,  the  controller  may  be  shut  off  and  the 
terminal  should  be  removed.  The  next  time  power  is  applied,  the  controller  will  discover 
that  no  terminal  is  attached,  it  will  consult  the  values  last  stored  in  page  0  to  see  what 
it  should  do,  and  it  will  perform  the  experiment  according  to  those  values. 


VI.     TESTING  OF  THE  SOFTWARE 

Even.-  module  of  the  software  has  been  tested  individually  for  correctness.  The  in- 
tegrated control  program  also  has  been  tested  exhaustively,  but  because  the  hardware 
has  not  yet  been  completely  integrated,  there  is  a  limit  to  what  could  be  accomplished. 
This  chapter  discusses  how  the  testing  has  been  performed  and  suggests  further  tests  to 
be  done  once  hardware  integration  is  complete. 

The  following  hardware  components  have  been  completed  and  have  been  success- 
fully operated  by  the  integrated  software: 

1.  Bubble  memory  for  the  experiment's  log. 

2.  Terminal. 

3.  Real  Time  Clock. 

4.  On-board  Analog-to-digital  (A  D)  converter. 

5.  Voltage  Controlled  Oscillator. 

6.  Power  Control  Subsystem. 

In  addition,  a  preliminary  design  of  the  Solid  State  Data  Recorder  (SSDR)  was  tested 
by  Kuebler  [Ref.  9].  His  tests  included  a  demonstration  that  the  ofT-board  analog-to- 
digital  converters  associated  with  the  SSDR  functioned  correctly,  that  the  SSDR  prop- 
erly stored  the  acoustical  data  provided  to  it  by  the  olf-board  analog-to-digital 
converters,  that  this  data  could  be  retrived  from  the  SSDR.  and  that  an  analysis  could 
then  be  performed  on  the  data.  The  final  version  of  the  SSDR  has  not  yet  been  com- 
pleted, and  in  the  testing  of  the  software  described  in  this  thesis,  no  attempt  has  been 
made  to  emulate  its  performance.  However,  the  controller  dutifully  sends  commands  to 
it  and  makes  repeated  (unsuccessful)  attempts  to  read  its  status  information.  It  also 
notes  its  inability  to  get  correct  responses  in  the  log. 

The  software  has  been  tested  many  times  under  various  conditions,  both  with  and 
without  a  terminal  attached.  A  test  requires  the  initialization  of  flags  in  page  0  of  the 
bubble  memory  log  in  advance.  How  to  do  this  is  explained  in  Chapter  V.  HOW  TO 
GET  THE  EXPERIMENT  READY  FOR  A  LAUNCH  on  page  63.  There  are  two 
ways  to  end  a  test,  depending  on  whether  or  not  a  terminal  is  attached. 

1.  If  there  is  a  terminal  attached,  pressing  CTRL  ^'  will  interrupt  the  experiment  and 
present  the  highest  level  menu  in  the  diagnostic  subsystem.  The  experiment  can 
be  resumed  bv  makine  choice 


Z.      Exit   this   menu. 

To  terminate  the  experiment  completely,  make  choice 

A.   Software  Reset. 

2.  If  there  is  no  terminal  attached,  simply  remove  power  from  the  system.  This  is,  in 
fact,  how  the  experiment  will  be  terminated  at  the  end  of  a  space  flight  (if  the  bat- 
teries last  long  enough.)  Attaching  a  terminal  and  applying  power  will  put  the 
control  program  into  the  diagnostic  subsystem. 

The  results  of  the  experiment  can  be  evaluated  by  making  menu  choice 

I  Examine  or  change  the  data  logged  in  the  bubble  memory. 

The  followmg  is  a  list  of  the  various  conditions  under  which  the  experiment  has  been 
tested.  The  conditions  are  listed  as  applying  and  not  applying,  where  this  is  meaningful. 
.AH  these  conditions  resulted  in  satisfactory  performance  by  the  controller. 

1.  Terminal  present;  terminal  absent. 

2.  Unabridged  experiment  to  be  performed;  abridged  experiment  to  be  performed. 

3.  Sn-eep  phase  previously  performed;  sweep  phase  not  previously  performed. 

4.  Launch  had  occurred  previously;  launch  had  not  occurred  previously. 

5.  Bubble  memory  space  exhausted  during  test.  The  controller  correctly  ceased  trying 
to  store  more  data  and  continued  to  operate  normally  without  logging  its  actions. 
This  could  not  be  verified  without  the  terminal  attached,  lor  with  neither  a  terminal 
nor  a  bubble  memory  log.  the  controller  does  not  generate  enough  outputs  for 
proper  verification  of  its  performance.  There  is  no  reason  to  suppose  that  the  re- 
sults would  be  diiferent  with  the  terminal  removed,  however. 

6.  Temperature  out  of  limits.  Operation  of  the  bubble  memory  ceased.  Power  was 
applied  to  and  removed  from  the  heater  subsystem  by  comniands  to  the  power 
control  subsystem.  These  commands  were  issued  by  the  subprogram  responsible 
for  monitoring  the  heater's  operation,  namely  monitor_heaters().  .Although  the 
heater  subsystem  itself  has  not  yet  been  completed,  the  associated  power  relays 
switched  correctly. 

7.  Detection  of  the  Auxihary  Power  Units  (APUs)  by  the  Matched  Filter  was  and  was 
not  emulated  by  toggle  switch.   The  controller  responded  correctly  in  both  cases. 

8.  Detection  of  launch  by  the  Vibration-activated  Launch  Detector  was  and  was  not 
emulated  by  toggle  switch.   The  controller  responded  correctly  in  both  cases. 

9.  Activation  of  the  Barometric  Pressure  Switches  was  and  was  not  emulated  by  tog- 
gle switch.  In  the  absence  of  activation  of  the  barometric  pressure  switches,  the 
presumption  is  that  launch  did  not  occur.    The  controller  responded  correctly  in 

both  cases. 

10.  Power  was  removed  abruptly  at  various  points  in  the  procedure  and  then  was  re- 
stored.   The  controller  recovered  in  the  desired  manner. 


After  each  test,  the  contents  of  the  bubble  memory  log  were  examined  to  see  what  steps 
m  the  experiment  had  been  performed.  Two  obvious  diOerences  were  found  between  the 
system's  behavior  with  and  without  a  terminal  attached.  One  of  these  was  that  with  a 
terminal  attached,  the  diagnostic  messages  issued  during  the  performance  of  the  exper- 
iment were  visible.  The  other  was  that  with  a  terminal  attached,  the  diagnostic  subsys- 
tem did  not  get  control.  No  other  difference  could  be  found  between  system  behavior 
with  and  without  a  terminal  attached. 

There  is  every  reason  to  believe  that  the  control  program  will  work  as  well  in  the 
Space  Shuttle  as  it  has  in  the  lab.  The  same  tests  should  be  performed  again  once  the 
hardware  is  completely  integrated.  The  only  tests  which  have  not  already  been  done  are 
those  associated  with  the  operation  of  the  Solid  State  Data  Recorder  (SSDR).  The 
interface  with  this  device  is  ver\'  simple.  The  controller  sends  commands  and  reads  sta- 
tus information.  The  SSDR  is  oiher\vise  completely  independent  of  the  controller.  We 
have  already  ascertained  that  the  application  of  power  to  the  SSDR  through  the  power 
control  subsystem  is  done  correctly.  We  have  also  verified  correct  response  to  a  failure 
of  the  SSDR  to  perform  as  expected.  The  only  thing  we  have  not  tested  is  the  response 
of  the  control  program  to  carreer  responses  from  the  SSDR.  Since  the  response  amounts 
to  making  a  note  of  the  correct  response  in  the  bubble  memor}-  log.  we  do  not  anticipate 
any  difTiculty  in  this  area.  The  ability  of  the  controller  to  send  commands  to  the  SSDR 
has  been  tested,  although  the  response  of  the  SSDR  to  these  commands  cannot  be 
evaluated  until  the  final  version  of  the  SSDR  is  complete. 

The  means  of  extraction  of  data  from  the  bubble  memor>-  log  are  not  ven.-  elaborate 
at  this  point.  Data  can  be  extracted  for  two  experiment  steps  at  one  time  by  providing 
the  number  of  the  page  in  the  bubble  memory  log  whose  contents  are  required.  No  ca- 
pability has  been  provided  for  rapid  extraction  of  all  data  to.  say.  a  microcomputer.  This 
does  not  pose  a  serious  problem,  but  data  extraction  would  be  facUitated  by  providing 
subroutines  to  do  it  quickly. 


VII.     CONCLUSIONS 

The  Vibro-acoustic  Experiment  was  the  first  experiment  produced  at  the  Naval 
Postgraduate  School  for  inclusion  in  a  Space  Shuttle  mission.  In  view  of  the  consider- 
able technical  hurdles  it  presented,  it  is  fair  to  say  it  has  been  a  ver\-  ambitious  project. 
It  has  included  many  disciplines,  such  as  mechanical  engineering,  thermal  engineering, 
digital  electronics,  analog  electronics,  acoustics,  bubble  memor\-  technology,  auton- 
omous computer  control,  software  development,  a  matched  filter  for  detecting  an  im- 
pending space  shuttle  launch,  power  control,  and  computer-aided  design  and 
manufacturing  (CAD  CAM). 

This  thesis  has  concerned  itself  with  overall  control  of  the  experiment  and  with  a 
description  of  one  subsystem,  the  matched  filter.  It  was  not  possible  to  do  this  without 
considering  the  experiment  as  a  whole.  From  the  author's  personal  standpoint,  this  has 
been  ver>-  gratifying.  We  have  used  a  high-level  programming  language  to  do  the  bulk 
of  the  programming  of  a  microprocessor-based  controller,  thus  avoiding  the  labor- 
intensive  burden  of  assembly  language  coding  in  most  areas  of  the  program.  We  have 
elTectively  integrated  this  code  with  the  little  assembly  code  required.  We  have  written 
drivers  for  assorted  hardware  devices,  such  as  a  terminal,  a  bubble  memon.-  module  and 
a  real-time  clock,  thus  demonstrating  the  close  association  between  hardware  and  the 
software  which  makes  that  hardware  more  than  a  glorified  paper-weight.  We  have  used 
structured  programming  techniques  throughout,  thus  aiding  the  design  process,  as  well 
as  the  understanding  of  the  documentation  represented  in  part  by  this  thesis.  We  have 
created  a  conveniently-used  software  development  system,  making  it  straightforward  to 
edit  the  source  files,  compile  or  assemble  them,  link  the  object  modules,  list  source  files 
on  a  printer,  and  place  the  executable  file  in  EPROM. 

This  work  may  benefit  others  who  would  like  to  implement  other  applications.  We 
have  made  it  possible  for  them  quickly  to  get  a  device  controller  programmed  and  op- 
erating, since  so  many  standard  controller  functions  already  exist.  The  C  programming 
language  is  highly  portable,  so  much  of  this  work  would  apply  even  with  a  new  hardware 
design,  using,  say,  a  faster  microprocessor  with  more  memory-. 

Two  other  projects  have  already  benefitted  from  the  work  done  here.  In  one,  the 
experimenters  plan  to  obtain  voltage  versus  current  for  solar  cells  in  space.  In  less  than 
two  months,  the  complete  control  program  for  that  new  application  was  designed  and 


tested  using  the  same  controller  and  much  of  the  software  we  have  described  in  this 
thesis. 

In  another  project  now  underway,  the  author  is  involved  in  the  experimental  evalu- 
ation of  a  thermo-acoustic  refrigerator  in  space.  The  details  of  the  experimental  proce- 
dure in  both  these  cases  differ,  but  the  overall  fundamentals  of  control  of  an  experiment 
are  the  same.  Consequently,  much  of  the  software  described  in  this  thesis  can  be  used 
without  any  modification. 

For  anyone  who  wants  to  build  a  controller  with  modest  requirements  for  speed  and 
R-AM.  the  controller  we  have  used  in  the  Vibro-acoustic  Experiment  would  be  suitable. 
By  using  the  work  described  in  this  thesis,  one  can  avoid  the  unpleasant  burden  of 
starting  from  scratch.  The  bubble  memory  module  provides  a  further  500K  bytes  of 
random  access.  non-\olatile  memory  for  wiiatever  purpose  might  be  required. 

Work  remaining  to  be  done  is: 

1.  Design,  build  and  test  an  improved  controller  which  would  operate  with  more 
memory  and  greater  speed. 

2.  Convert  the  existing  software  to  run  on  the  new  controller.  This  would  entail  re- 
placing the  start-up  code  and  other  machine-dependent  assembly  code,  and  re- 
compiling the  C  language  source  code  using  a  compiler  which  would  generate 
machine-language  code  for  the  new  target  machine.  Software  Development  Sys- 
tems. Inc..  makes  C  language  cross-compilers  which  would  allow  most  of  the  ex- 
isting set-up  to  be  preserved  intact. 

3.  Modify  the  existing  bubble  memory  drivers  to  permit  storage  of  files.  At  the  mo- 
ment, the  bubble  memory  is  regarded  as  a  linear  hst  of  64-byte  chunks  of  memor>'. 
Greater  usefulness  would  result  from  the  provision  of  a  file  subsystem. 

4.  Produce  a  manual  for  other  potential  users  of  the  software  and  hardware  that 
would  make  it  easy  to  get  new  applications  up  and  running  quickly.  This  could  be 
supplemented  by  improved  routines  to  facilitate  the  generation  of  executable  code. 
At  the  moment,  these  routines  are  specific  to  the  Vibro-acoustic  Experiment  in  that 
they  always  look  in  the  subdirectory  \vibro\contrJr  for  the  files  they  need.  In  gen- 
eral, they  should  permit  any  subdirector\-  to  be  used  to  hold  the  files.  The  exper- 
iment to  evaluate  solar  cell  performance  used  a  series  of  files  and  subdirectories 
whose  structure  exactly  mimicked  the  set-up  described  in  this  thesis,  but  no  rou- 
tines have  been  written  to  set  these  files  up  automatically. 

5.  Develop  or  acquire  a  software  maintenance  system.  Such  a  system  would  provide 
better  management  of  successive  versions  of  the  control  program.  It  would  also 
include  a  data  dictionan."  to  provide  a  definition  of  all  variables  and  functions, 
along  with  a  complete  cross-reference  showing  ever\'  place  these  objects  were  used. 
What  would  the  data  dictionary  gain  us?  It  often  happens  that  in  the  course  of 
making  changes,  we  inadvertently  affect  other  parts  of  a  system.  The  data  dic- 
tionary would  make  it  possible  to  find  all  those  places  and  take  appropriate  action. 


Microprocessors  have  now  been  in  use  for  just  a  little  over  15  years.  The  use  of 
compiled  programs  to  operate  them  is  an  even  more  recent  development,  since  compiled 
programs  generally  take  up  more  memory  space  than  assembled  programs,  and  abun- 
dant memory  at  low  prices  is  available.  There  are  two  distinct  advantages  to  using  a 
compiler: 

1.  The  code  is  easier  both  to  write  and  to  understand.  This  makes  it  easier  to  get 
applications  running,  and  to  modify  them  later,  even  if  team  members  change  over 
a  period  of  time. 

2.  The  code  is  much  faster  to  create.  This  often  makes  the  difference  between  success 
and  failure,  since  time  can  be  critical,  particularly  in  an  educational  environment. 

Often  these  advantages  outweigh  the  disadvantages: 

1.  The  code  tends  to  take  more  memory. 

2.  The  code  tends  to  execute  more  slowly. 

In  the  case  of  the  Vibro-acoustic  Experiment,  these  factors  were  of  no  great  conse- 
quence, except  as  already  noted  in  conjunction  with  the  bubble  memon.'  module.  We 
were  forced  to  use  assembly  code  to  operate  the  bubble  memon.-  in  order  to  keep  up  with 
the  data  transfer  rate  demanded  by  it.  Had  there  been  an  adequate  buffer  in  that  hard- 
ware, this  extra  elTort  could  have  been  avoided. 

In  fact,  this  last  point  makes  it  clear  that  good  hardware  design  can  greatly  reduce 
the  effort  {i.e.,  the  costs)  associated  with  software  development.  It  is  hard  to  believe  that 
the  job  of  implementing  a  64-byte  buffer  in  hardware  would  be  much  more  difficult  than 
that  of  implementing  a  40-byte  buffer.  Had  Intel  done  this,  we  would  have  been  spared 
months  of  development  difficulties,  during  which  we  did  not  understand  the  reason  why 
the  C  code  did  not  work. 

Finally,  the  use  of  a  compiled  language  which  is  highly  portable  (in  particular  a 
compiled  language  such  as  C)  can  help  protect  the  investment  of  time  and  money  in 
software  which  is  otherwise  threatened  as  obsolete  hardware  is  replaced  by  improved 
hardware.  In  the  software  industry,  endless  conversions  from  one  hardware  system  to 
a  new  one  seem  to  be  a  permanent  nuisance.  The  ability  to  take  old  programs  and  make 
them  work  on  new  hardware  simply  by  recompiling  them  is  attractive. 

Another  potentially  useful  step  would  be  to  implement  the  controller  software  using 
Ada,  the  Department  of  Defense  compiled  language  now  mandated  for  embedded  soft- 
ware in  all  purchased  systems.    This  would  have  the  advantage  that  Ada  programmers 


are  likely  to  become  more  and  more  numerous  over  time.  This  would  help  keep  the  work 
already  done  both  current  and  useful. 


APPENDIX  A.     DERIVATION  OF  DESIGN  EQUATIONS  FOR  THE 
MATCHED  FILTER 

This  appendix  presents  derivations  and  proofs  of  results  used  elsewhere  in  this  thesis. 

A.     BIQUADRATIC  FILTERS  USING  TWO  OPERATIONAL  AMPLIFIERS 

Figure  7  on  page  27  shows  the  topology  of  a  generalized  biquadratic  filter  using  two 
operational  amplifiers.  This  topology  is  taken  from  Michael  [Ref  15].  In  this  figure,  Y 
denotes  an  admittance  (the  reciprocal  of  an  impedance).  Michael  gives  ideal  transfer 
functions  in  the  5-domain  from  the  node  marked  r„  to  the  nodes  marked  T,.  V^,  and 
l\.  We  will  have  occasion  to  use  the  first  two  of  these.  Since  Michael  does  not  provide 
derivations  for  these  functions,  they  are  provided  below.  Note  that  the  term  "ideal" 
implies  the  use  of  operational  amplifiers  of  infinite  gain.  While  no  such  operational 
amplifiers  in  fact  exist,  there  do  exist  operational  amplifiers  of  ver\'  large  gain,  and  the 
approximation  is  practical  in  many  circumstances,  especially  at  the  low  frequencies  used 
in  the  \'ibro-acoustic  Experiment  {i.e.,  the  6()0  ilz  tone  from  the  Auxiliary-  Power  Unit). 
For  example,  the  open-loop  gain  of  the  LF-444  operational  amplifier  is  more  than 
60  dB  at  a  frequency /=  600  Hz. 

From  the  Kirkoff  current  law,  and  referring  to  Figure  7  on  page  27,  we  ha\e 

h  =  h  +  k  (35) 

/-  =  /,  -  /,  (36) 

/,  =  -  ly  (37) 
We  can  find  the  currents  /,  through  /g  by  applying  Ohm's  law. 

/i=(^'i-^4)>'.  (38) 

I^  =  {V,-V,)Y,  (39) 

/3  =  (^^2-n)>^3  (40) 

h  =  {V2-V,)Y,  (41) 

/5  =  (l5-J'/.v)>^5  (42) 
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(-13) 
(44) 
(45) 


By  substituting  these  currents  into  equations  (35)  through  (37),  we  obtain  the  following 
three,  independent  equations. 


(f- -rjr,  =  (r,-  i\)Y,. 

Collecting  these  terms  yields 

Tjll^-f  Y^+  Y,)=  [';}•;+  VjyYs 

\;{Y,-rY,+  Y,)=J\Y,+  \),Yj 

]\n]+Y,)=V,Y,  +  \-:Y,. 


(46) 
(47) 

(48) 

1-49) 
(50) 
(51) 


In  an  ideal  operational  amplifier,  the  inputs  have  equal  voltages,  so  we  can  write 
Tj  =  l\  =  l).  ■  Rewriting  the  equations  with  \\  in  place  of  \\  and  \\  gives 

V,{Y^+Y,^-  Y,)=\\Y,+  V,s)\  (52) 

V,[Y,+  Y-,+  Y,)=  \\y,-^Visyi  (53) 

V2{y^  +  y2)=y^y^  +  ^\y2^  (54) 

These  equations  can  be  readily  solved  by  placing  them  in  matrix  form  first. 

VjN-  (55) 


^2  +  ^'5  +  y. 

0 

-yi 

V3 

>5 

n+j'7+>8 

-y. 

0 

y-i 

= 

yi 

y,  +  y'3 

->'3 

-y^_ 

y^ 

_0 

Now  interchange  the  positions  of  \\  and  ^3. 


-  Y,         Y,  +  }  3 


Next  we  move  row  3  to  the  top. 


Ivi 

'yi 

f^3 

^ 

0 

-73      y,  +  73      -  y^ 

0        72+75+7,-72 
-74     74+7^+78       0 


>2]    To' 

V,    =     Y, 


f'/.v 


Vis- 


(56) 


(57) 


Next,  multiply  row  1  by  Y\,  row  3  by  7j,  and  subtract  the  latter  product  from  the 
former  to  generate  a  new  row  3. 


-  >  3  >'.  +  >3  -  y^ 

0  Y,  +  75  +  7,  -  7, 

0       -  }'3(  Y,  +  7-  +  Jg)  +  }-4( 7,  +  73)     -  }', }', 


[^'2 

^3 

0 

>'5 

[v,^ 

.-^■3>'^ 

(58) 


Now  multiply  row  2  by  [  -  Y^iY,  +  }'-  +  )',)  +  YJY^  +  }'3)].  row  3  by  {Y2  +  }'5  +  7,). 
and  subtract  the  latter  product  from  the  former  to  generate  yet  another  row  3. 


>  2  +  >'5  ^ 


•  >'i  >4<  >':  +  ^i  +  ^6)  +  >:[  -  >'3'  >4  +  >■-  +  >s»  +  >4<  >'i  +  >V] 


>'5 
■  >'3>'-(>2  +  >'5  +   ^-6)  -  >'5[  -  >'3(>'4  +  >'"  +  >'s)  +  >4(  >'l  +   ^Vl 


From  row  3,  we  can  see  that 


•  Y^  Y-{  Y2+  Yi+  Ye)  -  VjC  -  Y-^j  Yi+Y-+  Kg)  +  VJ  K,  +  Y\)l 
■  >'i  >^4l>2  +  >'5  +  >6)  +  Yll  -  Y^{Y,  +  K:  +  Ks)  +  Y,[Y,  +  ^3)] 


-  y'3 >%(  V;  +  Kg)  -  Y^ >5 K-  +  K3 y; K5  +  ^3 Fj K.  +  Vj Kj Kg  -  K,  ?; ^5  -  K3 K4 Kj 

-  r,  r4(  K5  +  K^)  -  >'i  >: ^^4  -  Yi  Yi n  -  1^2 y^  Yi  -  Yi > 3 n  +  ^'i  1^2 >'4  +  >2 ^3 n  ■ 


(59) 

(60) 
(61) 


Many  terms  in  the  numerator  and  in  the  denominator  of  this  expression  add  to  zero, 
so  the  transfer  function  is 


V\      -  73  7,(7;  +  7,)  +  737573  -  Y,  Y,Y, 
Vjs-    -YJ,{Y,+  Y,)-Y^Y,Y,-Y,Y,Y, 


(62) 


\y,Ys+y,y,{y2+y,)-Y\YsYs 

y,y,(r5+y;)+y2n(>'7  +  n)    ' 

(63) 


This  completes  the  derivation  of -7^7— .   To  derive  the  transfer  function   ,.        ,  we 
modify  equation  {:>:::)  bv  placing  the  variable  Tj  in  the  last  position. 


0      y,  +  y,+  }  3    -  }• 

-  >  1     y^  +  y3     -  y-. 


kl' 

[Ys] 

^2 

= 

Yi 

1  r; 

0  _ 

(64) 


Proceeding  as  before,  we  multiply  row  3  by  -  }',  .  row  1  by  -  }',.  and  subtract  the 
former  product  from  the  latter  to  generate  a  new  row  3. 


0  },  4-  Y-  +  y,  -  Y, 

0  >',(>2+   >'5^   >'6)-   >2(>'!+   >3)       >'2>3 


1 3  =    y- 
^2      yjs 


\)y.  (65) 


Next  multiply  row  2  by  [  }'.(};  ^  >;  +  };)  -  }',( }',  +  }j]  .  row  3  by  (};  +  }'-  +  Y,)  , 
and  subtract  the  latter  product  from  the  former  to  yield  a  new  row  3. 


-  >:     >:  +  >'5  ^  >6  0 

0       >•,  -  }•-  +  }\  -  Y, 

0     .  0  Y2  }'3(  }\  +  Y,  +  Y^)  +  nC  Fil } ;  +  }'j  +  Kg)  -  Y.J  }',  +  }'3)] 

}•- 

.  >"l  >"5l  >i  +  >"-  +  >S)  -   ^'-C  >1<  >2  +  >'5  +  >6)  -  >V>'l  +  >V'] 

From  row  3  we  can  see  that 


y. 


Y,Y,(Y,+  Y^  +  >g)  -  Y,  y.{ > 2  +  Ys  +  ^6)  +  >"2 >'7( ^^1  +  >^3) 


(66) 


(67) 


P  Vv        >':  Yii  Y^  -r  Y-  -  )  gj  +  r,  Y^{  Y2  +  Y5  +  Ye)  -  i 2  >4(  >'i  +  >'3)  ' 
As  before,  many  terms  in  both  the  numerator  and  the  denominator  add  to  zero,  so 


V\    _  Y,Ys{Y,+  Y,)+y2y3Yi-YJ,Y, 
I),.  Y2Y,(Y-+Ys)+YJ,{Ys+y6) 


(68) 


It  is  possible,  using  the  same  method  illustrated  in  both  these  cases,  to  develop  a 
transfer  function  — — — .  We  have  no  use  for  this  particular  function  in  the  present 
context,  however,  so  the  derivation  is  omitted. 

B.     HIGH-PASS  NOTCH  FILTER 

The  equation  of  a  notch  filter  is  given  in  equation  (6),  repeated  here. 

s'  +  cs,] 

Fi^y TTTT •  (6) 


Michael  [Ref.  15]  shows  how  to  use  the  generalized  configuration  of  Figure  7  on 
page  27  to  implement  this  function  in  the  case  where  co,  =  oj^.  which  is  the  case  for  a 

symmetric  notch  filter.  However,  he  does  not  show  how  to  implement  an  asymmetrical 
notch  filter,  in  which  co^  #  co.. 

We  can  do  so  by  using  equation  (63)  and  making  the  following  choices  for  the 
admittances  F,  through  )\. 

>',  =  Q  (69) 

Yi  =  sC,  (70) 

>3  =  Q  (71) 

Y,^Y,  =  G  =  -^  (72) 

>6  =  0  (73) 

Yi  =  ^Q  (74) 

n  =  f  (75) 


where  we  pick. 


(76) 


Proof 


i7-4'-(*)1 


(77) 


C^G'  +  s'Qd- 


Qp 


CaG 

'  +  ^'qq 

+  ^QQ 

<2p 

2 

-(^V- 

G' 

C,C(7 

S^  - 

l  cl  j^ 

^(i 

)^- 

5"  -r 

(f)!' 

G 


5--u;     1-1-       -r- 


(78) 


\t> 


Using  resistance  values  instead  of  conductance  values  in  equations  (76)  and  (77), 
we  get 


(79) 


(80) 


C.     LOW-PASS  NOTCH  FILTER 

To  get  a  low-pass  notch  filter,  we  use  equation  (68)  and  pick  admittances  as  follows: 

(81) 

(82) 
(83) 
(84) 


(35) 


Y 

=  Y,  =  G, 

Y2 

=  Y-  =  sC 

>3 

=  >4  =  G, 

^6  =  0 

'•=f 

u'here  we  pick 


and 


(86) 


(87) 


Proof 


G'ti  0,  +  -^  ]^s'C^G, 


GjG, 

-^  5' 

C'G, 

+  5C 

G.G, 

^'- 

Gt 

c 

y- 

i% 

(88) 


Converting  equations  (S6)  and  (87)  to  use  resistances  instead  of  conductances,  we 
get  the  design  equations 


(89) 


and 


(90) 


D.     A  SECOND-ORDER,  LOW-PASS  FILTER  USING  ONLY  ONE 
OPERATIONAL  AMPLIFIER 

Figure  14  on  page  36  is  the  schematic  of  a  generahzed  second-order,  low-pass  filter. 
The  general  equation  of  a  low-pass  biquadratic  filter  is  given  by  [Ref    12  :  p.  16]  as 


s   +l-^j^  +  -p 


(91) 


This  transfer  function  can  be  realized  by  the  schematic  in  Figure   14  on  page  36  if 
we  make  the  following  choices  for  the  components. 


Proof 


C,C,R,R, 


(92) 


Qp  = 


QR^R 


2    1 


Q       R^-^Ri' 


(93) 


/,  =  r^5Q  =  - 


l2  =  {Va-yo)sC, 


L=^^^^=I.  +  L. 


(94) 
(95) 
(96) 


From  equation  (94), 


f".  =  ^oi:i  +  ^Q/?2] 


(97) 


^;-  ^"c>=^VQ^2- 


(98) 


Thus 


=  Vob'c,C,R,+sC2'] 


(99) 


We  can  manipulate  this  equation  to  obtain  the  transfer  function. 


(100) 


^'/v        i-QC;/?;/?, +5Q(/?i +  /?.)^  1 
/ \ \ 


C.C^RR. 


r  -       [R-  -  R~) 


I 


^C^C:R-R: 


C,       I   /?,  +  R, 


(101) 


If  we  choose  i?,  =  7?j  =  /?,  then 


^vC,Q 


(102) 


and 


^^       2  V   C, 


(103) 


To  design  a  filter  to  provide  desired  values  of  co,  and  Q,,  ,  use  the  design  equations 
which  can  easily  be  derived  from  the  above  equations. 

1.  Pick  C2  arbitrarily. 

2.  Let  C,  =  4Q0. 

3.  UiR^  =  R,  =  R  = ■ 


APPENDIX  B.     CHOICE  OF  A  SOFTWARE  DEVELOPiMENT  SYSTEM 

A.  Z-80  ASSEMBLY  LANGUAGE 

The  Vibro-acoustic  Experiment  has  a  fairly  long  history*.  Long  before  the  author 
became  associated  with  the  project,  two  distinct  choices  for  a  software  environment! 5 
had  already  been  made.  Early  in  the  project  we  used  Z-80  assembly  language  for  pro- 
gramming the  controller.  An  ALTOS  eight-bit  microcomputer  running  under  Digital 
Research  Corporation's  Control  Program  for  Microcomputers  (CP,  M)  was  available. 
It  included  a  Z-SO  assembler  (MSO),  a  librarian  (LIBSO)  and  a  linker  (L80).  However, 
the  turnover  in  student  personnel  is  rather  high  at  any  educational  institution;  the  Naval 
Postgraduate  Scliool  is  no  exception.  .Assembly  language  is  often  not  the  best  choice  for 
a  project  whose  participants  do  not  remain  for  the  life  of  the  project,  since  assembly 
language  is  not  widely  known,  is  not  easy  to  learn,  and  is  highly  dependent  on  the  ar- 
chitecture of  the  machine  in  which  the  final  program  is  to  operate.  Many  dilTerent  ar- 
chitectures exist,  and  most  machines  have  unique  architectures.  Even  those  who  know 
how  to  program  with  assembh  language  often  are  averse  to  expending  the  vast  amounts 
of  time  required  to  use  it  for  any  but  the  most  trivial  programs. 

B.  CP/.M  AND  TOOLWORKS  C 

.As  a  consequence  of  these  facts,  one  of  the  early  participants  in  the  project  suc- 
cessfully promoted  a  switch  away  from  Z-80  assembly  language  to  the  C  programming 
language.  This  high-level  language  includes  powerful  operators  which  make  it  easy  to 
manipulate  the  bits  within  the  bytes  of  the  computer's  memory,  and  so  it  can  do  almost 
anything  that  can  be  done  in  assembly  language.  The  same  ALTOS  CP  M  system 
happened  to  have  Toolwork's  C  compiler  on  it,  and  so  we  used  it. 

When  the  author  joined  the  project,  little  progress  had  been  made  in  actually  writing 
the  control  program.  With  Captain  Frank  Mazur.  L'S.MC,  and  Captain  Ron  Byrnes, 
USA,  the  author  wrote  much  of  the  control  program  on  the  ALTOS  under  CP,  M  using 
the  Toolwork's  C  compiler. 


15  The  term  jo/hvare  environment  refers  to  the  computer,  the  operating  system,  the  program- 
ming language,  and  all  related  software  and  hardware  tools  used  to  program  a  computer.  The 
computer  on  vshich  the  development  of  software  is  done  need  not  necessarily  be  the  same  one  as 
that  in  which  the  completed  program  will  reside  and  be  executed.  In  the  case  of  the  Vibro-acoustic 
E.xperiment.  it  is  not  the  same  computer. 


Doing  so  proved  to  be  a  frustrating  business.  The  ALTOS  was  equipped  with  two 
eight-inch,  single-sided,  single-density,  floppy  diskette  drives.  These  could  contain  only 
around  250  Kbytes  of  data.  One  drive  had  to  contain  a  copy  of  the  CP  M  operating 
system  at  nearly  all  times.  The  ALTOS  was  quite  slow  by  present  standards;  it  was  not 
uncommon  for  a  compilation  to  take  five  minutes.  Due  to  the  limited  disk  space  avail- 
able, the  output  of  the  compiler  (an  8080  assembly  language  source  filei6  )  had  to  be 
transferred  to  another  diskette  before  assembly  could  proceed.  Assembly  typically  con- 
sumed a  further  five  minutes.  The  library-  program  was  quite  inconvenient  to  use,  but 
once  the  executable  modules  had  been  loaded  successfully  into  a  hbrary,  linking  was 
straightforward.   This  was  a  comparatively  quick  two-minute  process. 

Our  EPROM  writing  program  was  on  an  IBM-PC  using  Microsoft's  Disk  Operating 
System  (MS  DOS).  Furthermore,  that  machine  had  only  5  1  4  inch  diskettes.  So  we 
took  our  eight-inch  floppies  to  a  Zenith  Z-100  that  had  both  sizes  of  dri\es.  where  we 
converted  the  CP  M  file  containing  executable  code  into  an  MS  DOS  file  on  a  5  1  4  inch 
diskette. 

Finally,  we  loaded  the  executable  program  from  the  diskette  into  the 
EPROM-writing  program  and  created  the  firmware. 

C.     MS/DOS  AND  LNIVVARE  C 

It  should  not  have  taken  us  too  long  to  tire  of  this  agonizing  procedure.  In  fiict,  it 
was  over  a  year  before  we  began  seriously  to  search  for  an  improvement  in  the  form  of 
a  cross-compiler.  We  wanted  a  C-language  compiler  which  would  operate  on  an  IBM 
PC  using  MS  DOS,  and  which  would  generate  Z-SO  object  code.  Several  were  available. 
We  selected  the  Lni\\'are  C  Compiler  package  from  Software  Development  Systems, 
3110  Woodcreek  Drive,  Downers  Grove,  IL  60515.  This  product  is  a  complete  software 
development  system.  It  includes  a  C  compiler  which  produces  Z-80  assembly  code,  a 
Z-80  assembler,  a  librar\'  manager  to  store  object  modules  in  a  single  MS  DOS  library- 
file,  a  linker  to  convert  a  collection  of  object  modules  into  an  executable  file,  and  a  large 
collection  of  utility  programs,  useful  for  Usting  files,  converting  files  from  one  format  to 
another,  and  so  on.     The  compiler  implements  the  complete  C  language  defined  by 


16  The  Toolwork's  C  compiler  generates  8080  assembly  language  source  code.  The  NSC800 
on  the  controller  board  can  execute  Z-80  code,  a  subset  of  the  NSC800  instruction  set.  and  the  8080 
Instruction  set,  which  is  itself  a  subset  of  the  Z-80  instruction  set.  We  had  an  assembler  for  Z-80 
and  8080  code.  We  needed  two  Z-80  instructions  not  available  in  the  8080  instruction  set.  So  we 
embedded  Z-80  machine  code  in  the  8080  assembly  source  created  by  the  C  compiler  and  executed 
the  resultant  module  with  an  NSC800.    It  really  was  at  least  as  complicated  as  it  sounds! 


Kernighan  and  Ritchie  [Ref.  I6|.  It  also  includes  enhancements  similar,  but  not  identi- 
cal, to  those  proposed  by  the  American  National  Standards  Institute  (ANSI). 

It  took  a  little  time  to  convert  from  the  old  to  the  new  system,  but  the  results  were 
well  worth  the  efTort.  Because  the  performance  of  the  IBM  System  2  Model  80  on  which 
we  run  this  system  is  so  much  greater  than  that  of  the  Altos,  we  are  able  to  generate  a 
new  version  of  the  controller  program  in  much  less  time.  The  use  of  MS  DOS  also  has 
provided  significant  benefits.  We  have  made  extensive  use  of  hierarchical  file  directories 
in  order  to  group  files  in  a  logical  manner.  We  also  use  MS  DOS  batch  files  to  minimize 
the  amount  of  memon.-  work  necessan-'  to  execute  such  programs  as  the  compiler  and 
the  linker. 

The  documentation  supplied  with  the  UniWare  system  [Ref  17]  is  excellent.  Unlike 
most  C  compilers,  this  one  is  not  meant  to  produce  executable  code  running  under  an 
operating  system.  For  this  reason,  much  of  the  standard  library  supplied  with  other  C 
compilers  is  not  applicable,  and  is  not  supplied.  In  particular,  no  libran."  functions  are 
provided  to  perform  disk  input  or  output.  However,  common  output  formatting  rou- 
tines such  as  printfO  are  included. 

D.     GENERATION  OF  FIRMWARE  IN  EPROM 

We  use  the  Intel  program  pcpp  to  load  the  completely  linked  program  into  EPROM. 
The  L'niWare  software  can  create  a  symbol  table  showing  what  should  go  where.  Armed 
with  this  list,  one  can  load,  install,  and  test  the  new  version  of  the  program  in  short  or- 
der. 

Details  on  the  operation  of  this  program  are  presented  in  Section  2.  Getting  the 
Executable  Program  into  EPROM  on  page  146. 


APPENDIX  C.     HOW  THE  UNIWARE  SOFTWARE  USES  THE 
COMPUTER  MEMORY 

The  UniWare  software  regards  memory  as  comprised  of  a  number  of  named  regions. 
The  C  compiler  itself  creates  five  of  these  [Ref  17:  Compiler  section,  p.3].  These  are  the 
regions  code,  string,  const,  data,  and  ram.  There  are  three  further  software  regions: 
reset,  mbrkram,  and  stack.  The  purpose  of  each  region  is  described  below.  The  linker 
treats  each  region  as  a  unit  and  places  its  contents  in  memor\-  in  contiguous  storage  lo- 
cations. It  decides  how  to  do  this  based  on  instructions  in  the  file 
\vibro\contrlr\obiect\spec.  The  order  in  which  these  regions  appear  in  memor>-  is  speci- 
fied in  this  file,  and  reflected  both  in  Figure  19  on  page  44,  and  in  the  order  in  which 
they  are  described  here. 

reset  The  Z-SO  architecture  specifies  that  the  program  code  stored  at  memorv' 

location  0x0000  be  executed  whenever  the  microprocessor  receives  power 
or  a  hardware  reset  occurs.  The  reset  region  contains  an  appropriate 
start-up  program.    This  program  does  the  following: 

1.  It  initializes  the  stack  pointer  to  0x0000.  Whenever  an  item  is  stored  in 
the  stack,  the  stack  pointer  is  first  decremented.  Thus,  the  stack  pointer 
will  initially  be  decremented  to  OxfilT.  the  first  location  in  the  stack,  and 
will  continue  to  grow  downward  in  memory  from  this  point. 

2.  It  initializes  the  interrupt  tables  in  such  a  manner  that,  should  a  spurious 
interrupt  occur,  the  control  program  will  restart  from  the  beginning.  It 
would  be  preferable  to  resume  execution  by  simply  returning  from  the 
interrupt.  This  would  raise  the  unacceptable  possibility,  however,  of  an 
indefinite  suspension  of  the  execution  of  the  program  if  some  unpredict- 
able cause  led  to  the  problem.  While  restarting  has  the  disadvantage  of 
totally  disrupting  matters,  its  compelling  advantage  is  that  execution  re- 
sumes from  a  known  state,  barring  a  complete  catastrophe. 

code  This  region  contains  all  program  instructions  generated  by  C  and  assembly 

language  source  code.    It  includes  code  to  do  the  following  things: 

1.  Program  variables  must  be  in  RAM  to  be  altered.  In  the  C  program- 
ming language  it  is  possible  to  assign  initial  values  to  these  variables  at 
the  time  a  program  is  compiled.  These  values  must  be  placed  in 
EPROM,  since  otherwise  they  would  be  lost.  One  of  the  routines  in  the 
code  region  is  invoked  at  start-up  time  to  copy  initialized  variables  from 
their  permanent  locations  in  region  data  in  EPROM  into  temporary-  lo- 
cations in  R.\M.  Thus  in  Figure  19  on  page  44  region  data  appears  in 
two  locations,  both  in  EPROM  and  in  R.-\M. 


2.  The  definition  of  the  C  programming  language  specifies  that  statici"  and 
externallS  variables  which  have  no  initial  value  specified  in  their  decla- 
rations must  be  initialized  by  the  compiler  to  the  value  0  [Ref  16:  p.l9S|. 
One  of  the  routines  in  the  code  region  is  invoked  at  start-up  time  to  put 
zeros  in  all  R.-\.\I  locations  in  region  ram. 

3.  Another  routine  which  is  invoked  at  start-up  time  calls  the  C  program 
main().  This  is  the  highest  level  program  in  C.  It  calls  subordinate 
routines  to  operate  the  controller  and  run  the  experiment  itself 

string  Whenever  the  compiler  finds  a  quoted  character  string  in  the  source  code, 
it  places  it  in  the  string  region.  Since  strings  are  treated  as  constants,  they 
can  be  kept  in  EPR0M.19 

const  Variables  declared  as  const  are  regarded  by  the  compiler  as  invariant,  or 

constant,  so  it  is  reasonable  to  place  them  in  EPROM. 

data  This  region  contains  variables  whose  initial  values  were  specified  at  the  time 

of  compilation.  These  values  are  placed  in  EPROM  by  the  linker  so  that 
they  will  not  be  lost  when  power  is  removed  from  the  controller.  However, 
variables  must  be  in  R.-\M  when  the  program  executes.  During  the  start-up 
procedure,  they  are  copied  into  R.-\\I. 

ram  This  region  contains  variables  whose  initial  values  were  not  specified  at  the 

time  of  compilation.  These  are  initialized  to  0  at  the  time  the  program  is 
first  invoked,  as  specified  in  Kernighan  and  Ritchie  [Ref    16  :   p.  198]. 

mbrkram  The  UniWare  C  compiler  provides  a  function  nibrk()  to  permit  a  program 
to  request  storage  at  run  time  (i.e..  dynamically).  The  mbrkram  region 
provides  mbrk()  with  the  storage  it  needs. 


stack 


The  program  stack  is  located  here,  at  the  top  of  memory. 


The  linker  ensures  that  items  within  a  region  are  stored  contiguously.  The  compiler 
decides  where  to  put  these  partitions  in  memory  by  examining  a  memory  map  provided 
in  the  specification  file  \vibro\contrlr\ob]ect\spec,  listed  in  Section  A.  Filename  spec  on 
page  150.   The  format  of  this  file  is  described  in  [Ref  17:  Link  Editor  Section,  p.  7]. 

The  memor>-  map  specifies  that  reset  be  loaded  at  address  OxUOOO,  that  the  stack 
grow  down  in  memor>-  from  address  OxffTf,  that  EPROM  is  available  from  addresses 
0x0000  through  OxSfiT,  and  that  R.AM  is  available  starting  from  address  OxeOOO  through 
OxfiTT. 


17  Static  vanables  retain  their  values  even  after  the  program  which  declared  them  finishes  ex- 
ecuting. 

18  E.xtemal  variables  are  declared  in  some  module  other  than  the  one  in  which  a  program  using 
these  vanables  is  defined. 

19  In  general,  to  modify  strings  a  programmer  must  first  place  a  copy  of  them  into  a  variable. 
Dynamic  vanables  are  always  located  in  RAM,  since  their  contents  are  changeable. 


APPENDIX  D.     HIERARCHICAL  ORGANIZATION  OF  SOFTWARE 
FILES 

All  the  software  to  control  the  Vibro-Acoustic  Experiment  is  located  in  the  file  hi- 
erarchy illustrated  in  Figure  35  on  page  89.    Following  is  a  description  of  the  contents 

of  each  of  these  subdirectories. 

A.  SUBDIRECTORY  \VIBRO\CONTRLR\HEADERS 

This  subdirectory  contains  header  files  for  the  C  language  source  code.  The  header 
flies  allow  numeric  constants  which  are  used  in  creating  the  program  to  be  specified 
symbolically.  By  avoiding  the  use  of  "magic"  numbers  in  the  source  code,  the  code  is 
rendered  much  more  readily  understood.  The  header  files  also  contain  external  declara- 
tions of  the  functions  and  variables  contained  within  a  module.  Whenever  one  module 
needs  to  use  the  functions  or  variables  of  a  dilTcrent  module,  it  can  obtain  correct  dec- 
larations of  them  by  including  the  appropriate  header  file  using  the  C  programming 
language  ^include  directive. 

B.  SUBDIRECTORY  \VIBRO\CONTRLR\CSOURCE 

This  subdirector\-  contains  C  language  source  code  for  the  parts  of  the  controller 
program  written  in  the  C  programming  language. 20 

C.  SUBDIRECTORY  \VIBRO\CONTRLR\AS.MSOURC 

This  subdirectoiw  contains  Z-80  assembly  language  source  code.  A  few  of  the  lowest 
level  routines  in  the  controller  software  have  been  written  in  assembly  language,  but  only 
when  there  was  no  apparent  way  to  write  them  in  C  {e.g.,input{),  output()),  or  when  the 
C  compiler  couldn't  generate  code  which  would  execute  rapidly  enough  (e.g.,  bubread() 
and  bubnriteO). 

D.  SUBDIRECTORY  \VIBRO\CONTRLR\BATCH 

This  subdirectory  contains  a  number  of  MS/DOS  "batch"  files.  These  contain  se- 
quences of  commands  which  make  it  easier  to  compile  programs,  print  listings  of  the 
source  code,  link  object  modules,  and  load  executable  modules  into  EPROMs. 


20  This  comprises  most  of  the  controller  software. 
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Figure  35.  Hierarchical  Organization  of  .SortN\aie  Files:  I  he  software  files  are 
grouped  into  <:e\eral  diflercnt  sub-directories  to  facilitate  finding  and 
managing  them. 

E.  SUBDIRECTORY  \\  lBRO\COiNTRLR\LlST 

I  hi<;  subdiiectory  contains  outpiut  Hsting<;  produced  either  by  the  C  compiler  or  by 
the  Z-80  assembler. -1  1  hose  created  from  C  source  code  include  that  code  in  the  form 
of  comments  to  the  Z-SO  assembler.  1  hey  are  stored  in  this  subdiiectory  only  as  a 
matter  of  convenience,  in  order  that  they  not  clutter  up  the  directory  li-^ting  of  the  sub- 
directories containing  the  source  code. 

F.  SUBDIRECTORY  \VIBRO\CO.NTRLR\OBJECT 

1  his  subdirectory  contains  object  modules  produced  either  by  tlie  C  compiler  or  by 
the  Z-SO  assembler.  Tiiey  are  stored  in  this  subdirectory  only  as  a  matter  of  conven- 
ience, in  Older  that  they  not  clutter  up  tiie  subdirectories  containing  the  source  code. 


21  Those  produced  by  the  C  coinpiJer  are  actually  assembly  language  listings  produced  by  the 
Z-80  assembler.   The  latter  is  called  by  the  C  compiler. 


This  subdirecton'  also  contains  the  link  specification  file  spec.  This  file  provides  the 
linker  with  information  needed  to  decide  where  the  various  regions  of  the  program  must 
be  loaded.   A  number  of  global  variables  are  set  by  this  file  at  link  time. 

For  details  on  how  to  use  a  link  specification  file,  see  the  discussion  in 
[Ref.   17:  Link  Editor  Section,  p.  7]. 


APPENDIX  E.     SUBROUTINES,  IN  ALPHABETICAL  ORDER  BY  NAiME 


Table  8. 


SUBROLITINE  INDEX:     This  table  shows  the  names  of  the  MS,  DOS 

files  in  which  each  subroutine  can  be  found.    Subroutines  are  listed  al- 
phabetically bv  name. 


SUBROUTINE 

SOURCE 
FILE 

PURPOSE 

ad_read() 

e.xpmnt.c 

Gets  a  character  of  data  from  the  Analog- 
to-digital  (A  D)  Converter. 

adtointO 

e.xpmnt.c 

Converts  a  character  of  raw  data  from  the 
Analog-to-digital  (A  D)  Converter  into  an 
integer  format  with  the  more  meaningful 
units  of  volts  or  dearees  kelvin. 

alter_pageO() 

e.xpmnt.c 

Permits  the  u^cr  to  alter  the  contents  of  page 
U  of  the  bubble  memor}'.    This  is  required  in 
initializing  the  experiment. 

allo\v_ctrlJnterrupts() 

incut. c 

Processes  the  special  characters  C  IRL  S  and 
CTRL  ^'  when  read  from  the  keyboard. 
CTRL  S  is  a  toggle  switch.    The  first  time  it 
is  pressed,  the  display  halts.  The  second  time 
it  is  pressed,  the  display  resumes.    Subse- 
quently Its  function  alternates  between  these 
two.    CTRL  Y  invokes  the  diagnostic  sub- 
system. 

atohi ) 

con\ert.c 

Converts  an  ASCII  string  representation  of 
a  hexadecimal  byte  into  the  corresponding 
hexadecimal  byte.    For  example,  the  string 
"a?"  IS  converted  to  the  bvte  value  oxaj. 

atohe,xint() 

convert.c 

Converts  a  four- byte  .ASCII  string  repres- 
enting a  two-byte  hexadecimal  word  into  the 
corresponding  hexadecimal  word.    For  ex- 
ample, the  string  "a34b"  is  converted  to  the 
word  Oxa3-}b. 

atolQ 

convert. c 

Converts  a  string  representing  a  decimal  in- 
teger into  the  corresponding  integer.   This 
subroutine  is  from  Bilofsky  [Ref  18]. 

bad_idea_to_record() 

expmnt.c 

This  routine  is  used  in  the  abridged  exper- 
iment to  prevent  record  mode  from  being  re- 
started after  a  power  fault.   Without  this 
safeguard,  perfectly  good  data  recorded  dur- 
ing launch  mieht  be  erased. 

baro_s>vitch() 

expmnt.c 

Checks  to  see  if  the  barometric  switches  have 
been  activated  yet.    If  so,  launch  must  have 
occurred  and  an  appropriate  log  entry  is 
made. 

bcd_asc() 

convert.c 

Converts  a  BCD  byte  to  the  corresponding 
character  string  representation.    For  exam- 
ple, 0x17  is  converted  to  "17". 

bcd_int() 

convert.c 

Converts  a  one-byte  BCD  number  to  integer 
format. 

bpagesetO 

bubble.c 

Loads  the  five  parametric  registers  in  the 
bubble  memory  controller.    Most  of  these 
never  change.   Two,  however,  do  change  of- 
ten.   These  two  specify  the  page  of  bubble 
memory  where  transfers  of  data  begin.   Call 
this  function  prior  to  any  operation  per- 
forming input  from  or  output  to  the  bubble 
memory  to  ensure  the  parameters  are  cor- 
rectly specified. 

bubcmdnienuO 

bubble. c 

Displays  a  menu  of  low-level  bubble  memory 
controller  commands.    These  are  useful  in 
testing  the  bubble  memory  for  proper  oper- 
ation. 

bubinitO 

bubble.c 

Initializes  the  bubble  memory  prior  to  its 
being  used.    This  initialization  must  always 
be  done  after  power  is  applied  and  before 
input  and  output  operations  begin. 

bubioO 

bubble.c 

Performs  input  from  and  output  to  the  bub- 
ble memory. 

bubmenuQ 

bubble.c 

Provides  a  menu  of  functions  permitting  the 
user  to  perform  operations  with  the  bubble 
memory.    These  operations  include: 

1.  applying  and  removing  power. 

2.  initialization, 

3.  input, 

4.  output  and 

5.  reading 

the  status  of  the  bubble  memor}-. 

bub_off() 

bubble.c 

Removes  power  from  the  bubble  memory. 

bub_on() 

bubble.c 

Applies  power  to  the  bubble  memon.'. 

bubreadO 

bubnv.s 

Takes  care  of  the  actual  transfer  of  data  from 
the  bubble  memor>-  to  the  controller  memor>- 
during  a  read.    This  routine  was  written  in 
assembly  language  in  order  to  achieve  a  data 
transfer  rate  of  16  K  bytes  per  second  im- 
posed by  the  bubble  memor>-  hardware. 

bub»rite() 

bubnv.s 

Takes  care  of  the  actual  transfer  of  data  to 
the  bubble  memory  from  the  controller 
memory  during  a  write.   This  routine  was 
written  in  assembly  language  in  order  to 
achieve  a  data  transfer  rate  of  16  K  bytes  per 
second  imposed  by  the  bubble  memor\- 
hardware. 

bub.\fer( ) 

bubn\.s 

Part  of  the  sequence  of  steps  necessar>-  to 
initialize  the  bubble  memory  entails  trans- 
ferring the  byte  Oxff  to  the  bubble  memor\- 
40  times.    This  routine  does  this.    The  rou- 
tine is  written  in  assembly  language  for 
speed,  but  is  called  in  the  same  manner  as  a 
C  routine. 

checkprtO 

expmnt.c 

Checks  to  see  whether  or  not  there  is  a  ter- 
minal connected  to  the  RS-232C  serial  inter- 
face port. 

clocking) 

clock.c 

Date";  and  times  in  the  real  time  clock  are 
stored  in  BCD  formal.  This  routine  converts 
them  to  integer  format  to  make  it  convenient 
to  perform  arithmetic  with  them.    Thus,  fu- 
ture dates  and  times  can  be  computed. 

ciockj-ead( ) 

clock.c 

Reads  the  current  date  and  time  from  the 
real  time  clock. 

clockcoinparel ) 

clock.c 

Compares  two  clock  times  to  see  which  one 
i<;  later  than  the  other. 

clockseti ) 

clock.c 

Sets  the  current  date  and  time  in  the  real 
time  clock  according  to  values  specified  by 
the  user. 

clocksumO 

clock.c 

Adds  two  dates  and  times  together  to 
produce  a  new  date  and  time.    In  practice, 
one  uses  this  to  calculate  a  future  date  and 
time  from  the  current  date  and  time  and 
some  desired  delay  {e.g.,  15  minutes). 

colder_than() 

expmnt.c 

Returns  the  value  TRUE  if  the  bubble 
memory's  temperature  is  below  the  temper- 
ature given  in  the  argument  to  the  function, 
FALSE  otheruise. 

ctohO 

convert. c 

Converts  a  single  character  to  its 
hexadecimal  .ASCII  string  representation. 
For  example.  Oxa3  is  converted  to  "a}"'. 

delayO 

delay.s 

Provides  a  software-driven  time  delay  in  in- 
crements of  10  ms.    Written  in  assembly 
language,  but  used  like  a  C  language  routine. 
Adapted  from  a  program  by  Mr.  David 
Rigmaiden  of  the  Naval  Postgraduate 
School. 

display_pageO() 

expmnt.c 

Displays  the  contents  of  page  0  in  a  readable 
format. 

display_data_page() 

expmnt.c 

Displays  the  contents  of  any  page  in  the 
bubble  memor>-  in  a  readable  format.    It  will 
not  successfully  display  page  0.    Use 
display_pageO()  for  this  purpose. 

do_s>veep() 

expmnt.c 

Causes  the  sweep  phase  of  the  experiment  to 
be  performed. 

dumpO 

inout.c 

Produces  a  hexadecimal  and  ASCII  dump 
of  any  desired  region  of  memor>". 

dump_clock{) 

clock.c 

Display  the  date  and  time  on  the  terminal. 

dumpJcIockO 

clock.c 

Display  the  date  and  time  on  the  terminal. 
This  diilers  from  dump_clock()  in  that  the 
dates  and  times  it  uses  are  integers,  not  Bi- 
nary Coded  Decimal  (BCD)  numbers. 

echo( ) 

inout.c 

Sends  a  single  character  to  the  terminal. 

expmntO 

expmnt.c 

Causes  the  \'ibro-acoustic  Experiment  to  be 
performed. 

fputcO 

fputc.c 

The  LNIW.ARE  compiler  provides  the 
standard  C  output  routine  printfO  to  provide 
output  to  the  standard  output  device.    How- 
ever, this  routine  requires  the  user  to  provide 
a  routine  fputc()  to  handle  the  output  of  a 
single  character  to  any  arbitran."  device.    We 
only  support  output  by  fputcO  to  the 
RS-232C  terminal,  so  this  routine  is  specific 
to  that  device.    The  routine  will  noi  output 
a  character  if,  upon  checking,  it  find"^  there 
is  no  terminal  attached  to  the  serial  interface 
port.   Thus,  when  the  experiment  is  operat- 
ing, calls  to  printfO  are  of  no  effect  unless 
there  is  a  terminal  connected. 

gethexO 

inout.c 

Inputs  a  string  representation  of  a  two-digit 
hexadecimal  number  from  the  terminal  and 
converts  it  to  hexadecimal  format.    For  ex- 
ample, "3a''  is  converted  to  Ox3a. 

gethexintO 

inout.c 

Gets  a  four-digit  hexadecimal  number  in 
string  format  from  the  terminal  and  converts 
it  to  a  hexadecimal  word.    For  example, 
"3ab2*'  is  converted  to  Ox3ab2. 

getintO 

inout.c 

Inputs  a  string  representation  of  a  decimal 
integer  from  the  terminal  and  converts  it  to 
integer  format.    For  example,  "352"  is  con- 
verted to  352. 

getpagenoQ 

inout.c 

Asks  the  user  for  a  page  number  in  bubble 
memor\-. 

2et_time() 

clock.c 

Obtain  a  valid  date  and  time  from  the  user. 

inithardnareO 

initial. c 

Initializes  the  six  ports  on  NSC810A  ??1  and 

inputO 

nenio.s 

Inputs  a  character  from  a  port.   Written  in 
assembly  language,  but  used  like  a  C  lan- 

suase  routine. 

int_bcd( ) 

convert. c 

Converts  an  integer  in  the  ranse  0  through 
99  to  BCD  format. 

issububcmdi) 

bubble.c 

Issues  commands  to  the  bubble  memory 
controller  and  analyzes  the  status  codes 
which  result.    In  many  cases,  it  will  attempt 
to  issue  a  command  repeatedly  if  there  is 
some  failure,  doing  this  up  to  a  specified 
number  of  times.    This  routine  is  written  in 
C  and  is  not  fast  enough  to  handle  the  read 
and  write  commands.    Use  bubread()  and 
buburite( )  for  the'^e. 

itoa( ) 

convert. c 

Converts  an  integer  to  an  ASCII  string  rep- 
resentation.  This  subroutine  is  from  Bilofskv 
[Rcf  IS]. 

listenO 

expmnt.c 

Listens  for  the  Auxiliary  Power  Units 
(.APUs)  to  be  activated.    It  also  monitor";  the 
Vibration-activated  Launch  Detector  and 
the  Barometric  Pressure  Switches  to  see  if  a 
launch  has  occurred  without  detection  of  the 
activation  of  the  APUs. 

logeventl ) 

expmnt.c 

Makes  entries  into  the  event  log  stored  in  the 
bubble  memor\-. 

log_menu() 

expmnt.c 

Displays  a  menu  to  provide  for  conveniently 
changing  the  contents  of  bubble  memor>-. 
This  is  essential  for  properly  imtiating  the 
experiment. 

look_ahead() 

inout.c 

This  program  can  see  whether  a  character 
has  been  input  from  the  keyboard  without 
disturbing  the  input  buffer. 

mainO 

main.c 

First  C  language  subroutine  to  get  control 
after  start-up.    Decides  whether  to  invoke 
the  menu-driven  diagnostic  routines  or  to 
run  the  N'lbro-acoustic  Experiment. 

mbrkO 

mbrk.s 

Implements  the  C  language  standard  library 
function  mbrk().   This  function  was  provided 
with  the  Uniware  C  Compiler. 

memor>_dump() 

main.c 

Asks  the  user  for  an  address  in  memon.'  and 
the  number  of  bytes  he  wants  to  see  dis- 
played.   It  then  provides  a  hexadecimal  and 
ASCII  display  of  the  contents  of  the  selected 
area  of  memory  on  the  terminal. 

menu() 

main.c 

Displays  the  first  in  a  hierarchy  of  menus 
permitting  the  user  to  test  subsystems  of  the 
Vibro-acoustic  Experiment  individually. 

monitor_heatersO 

expmnt.c 

Operates  the  heaters  if  the  temperature  of 
the  bubble  memor\-  is  too  cold.    If  the  tem- 
perature is  too  hot,  it  shuts  the  heaters  off. 
Otherwise  it  leaves  the  heaters  alone. 

outputO 

nenio.s 

Outputs  a  byte  to  a  port.    Written  in  assem- 
bly language,  but  used  like  a  C  language 
routine. 

portdumpO 

inout.c 

Outputs  a  string  to  the  terminal. 

post_launch() 

expmnt.c 

Conducts  routine  monitoring  of  events  upon 
the  completion  of  the  N'lbro-acoustic  Exper- 
iment.   These  functions  continue  until  the 
Space  Shuttle  returns  to  earth,  or  until  the 
lUV  bus  no  longer  carries  suilicient  voltage 
for  safe  operation  of  the  bubble  memories. 
In  the  latter  case,  the  experiment  stops  all 
operations. 

poner_status() 

poner.c 

Inputs  the  one-byte  status  code  from  the 
power  relay  subsystem. 

poner_\>rite() 

po^ver.c 

Sends  a  one-byte  command  code  to  the 
power  relay  subsystem. 

p>vrcnt() 

poner.c 

A  menu  program  which  let's  the  user  read 
the  status  code  from  the  power  relay  subsys- 
tem or  send  commands  to  it. 

rdstatregO 

bubble.c 

Reads  the  status  register  of  the  bubble 
memorv  controller. 

recordO 

expmnt.c 

Performs  the  record  phase  of  the  abridged 
experiment. 

rtcQ 

clock.c 

A  menu  routine  allowing  the  user  to  set  or 
read  the  clock,  and  to  test  the  time-out  fea- 
ture (see  testtimeoutO  in  this  table). 

short_experiment() 

expmnt.c 

Performs  the  abridged  Vibro-acoustic  Ex- 
periment. 

showbubbuffO 

bubble.c 

A  bufier  exists  in  the  controller's  memory  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memor}'.    This  routine  displays 
the  contents  of  that  buffer  either  in  ASCII 
characters  or  hexadecimal. 

show_event() 

expmnt.c 

Converts  an  event  code  into  an  intelligible 
message  which  it  then  displays  on  the  termi- 
nal. 

show_\\aketime() 

clock.c 

Displays  the  date  and  time  when  a  time-out 
will  end. 

shut_do\>nO 

expmnt.c 

Removes  power  from  any  subsystems  which 
presently  have  power.    It  makes  a  log  entry 
for  each  such  case. 

shut_do\\n_noJog( ) 

expmnt.c 

Removes  power  from  any  subsystems  which 
presently  have  power.    It  makes  no  log  entry 
of  its  actions. 

ssdrmudel ) 

expmnt.c 

Issues  commands  to  the  Solid  State  Data 
Recorder  (SSDR)  to  enter  various  modes  of 
operation. 

ssdr_status() 

expmnt.c 

Obtains  the  status  code  from  the  Solid  State 
Data  Recorder  (SSDR). 

termini ) 

iiiout.c 

Inputs  a  Mngle  character  from  the  tcrnunal. 

testinputo 

inout.c 

Asks  the  user  for  a  hexadecimal  port  address, 
reads  that  port  and  displays  the  data  read 
from  that  port. 

testioO 

■ 

main.c 

This  routine  permits  the  user  to  perform  in- 
put from  and  output  to  any  port  in  the  sys- 
tem.   By  "port"  we  mean  here  an  address  in 
the  input  and  output  space. 

testoutputf ) 

inout.c 

Asks  the  user  for  a  hexadecimal  port  address 
and  a  hexadecimal  b>te  to  be  sent  to  the 
port,  and  sends  it  there. 

testpatternO 

bubble.c 

A  buffer  exists  in  the  controller's  memor>-  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memory.   This  routine  permits 
the  user  to  modifv  the  contents  of  that 
buffer. 

testtimeoutO 

clock.c 

Lets  the  user  test  the  time-out  feature.    For 
example,  he  can  request  a  delay  of  15  sec- 
onds.   During  this  delay,  the  control  pro- 
gram will  not  respond  to  input.   At  the  end 
of  this  period,  it  will  display  the  current  date 
and  time. 

timeoutO 

clock.c 

In  one  mode  of  operation,  this  function 
computes  a  "wake-up"  time  based  on  the 
current  time  and  a  specified  delay.    In  an- 
other mode,  it  checks  to  see  if  a  "wake-up*' 
time  computed  earlier  has  arrived  or  not. 

tolo»er() 

convert.c 

Converts  upper  case  characters  to  lower 
case.   Non-alphabetic  characters  are  not 
changed.   This  subroutine  is  from  Bilofskv 
[Ref  18]. 

uitohO 

convert.c 

Converts  an  unsigned  integer  to  the  corre- 
sponding hexadecimal  ASCII  string  repre- 
sentation.  For  example,  45  is  converted  to 
"2D" 

versionO 

version. c 

Displays  the  current  version  number  of  the 
control  program  on  the  terminal. 

voltages_lo>v() 

expmnt.c 

Checks  the  lOV  bus.   If  the  voltage  has  fallen 
too  low,  this  function  returns  the  value 
TRUE;  otherwise  it  returns  the  value 
FALSE. 

>ve_launched() 

expmnt.c 

Checks  for  any  indications  of  a  launch. 
These  can  come  from  the  \'ibration-activated 
Launch  Detector  or  from  the  Barometric 
Pressure  Switches. 
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F^LE^^^           SUBROLTINE 

PLRPOSE 

bubble.c 

bpagesetl) 

Loads  the  five  parametric  registers  in  the 
bubble  memop.'  controller.    Most  of  these 
never  change.   Two.  however,  do  change  of- 
ten.  These  two  specify  the  page  of  bubble 
memor\-  where  transfers  of  data  begin.    Call 
this  function  prior  to  any  operation  per- 
forming input  from  or  output  to  the  bubble 
memory  to  ensure  the  parameters  are  cor- 
rectly specified. 

bubble. c               bubcmdmenu( ) 

Displays  a  menu  of  low-level  bubble  memory 
controller  commands.   These  are  useful  in 
testing  the  bubble  memon."  for  proper  oper- 

bubble.c            '  bubiniti ) 

Initializes  the  bubble  memory  prior  to  its 
being  used.   This  initialization  must  always 
be  done  after  power  is  applied  and  before 
input  and  output  operations  begin. 

bubble.c               bubioi  ) 

Performs  input  from  and  output  to  the  bub- 
ble mcmor>-. 

bubble.c 

bubmenuO 

Provides  a  menu  of  functions  permitting  the 
user  to  perform  operations  with  the  bubble 
memory.    These  operations  include: 

1.  applying  and  removing  power. 

2.  initiahzation. 

3.  input, 

4.  output  and 

5.  reading 

the  status  of  the  bubble  memon.-. 

bubble.c               bub  off( ) 

Removes  power  from  the  bubble  memor>-. 

bubble.c               bub_nn(  i                        i  .Applies  po'.ver  to  the  bubble  memory.               | 

bubble.c 

issububcmdO 

Issues  commands  to  the  bubble  memory 
controller  and  analyzes  the  status  codes 
which  result.    In  many  cases,  it  will  attempt 
to  issue  a  command  repeatedly  if  there  is 
some  failure,  doing  this  up  to  a  specified 
number  of  times.    This  routine  is  written  in 
C  and  is  not  fast  enough  to  handle  the  read 
and  write  commands.    Use  bubreadQ  and 
bubwriteO  for  these. 

bubble.c 

rdstatregO 

Reads  the  status  register  of  the  bubble 
memory  controller. 

bubble.c 

sho\vbubbuff() 

A  buffer  exists  in  the  controller's  memon.-  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memor\-.    This  routine  displays 
the  contents  of  that  bufler  either  in  ASCII 
characters  or  hexadecimal. 

bubble.c 

testpatternO 

A  bulfer  exists  in  the  controller's  memory  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memory.    This  routine  permits 
the  user  to  modifv  the  contents  of  that 
buffer. 

bubnv.s 

bubreadO 

Takes  care  of  the  actual  transfer  of  data  from 
the  bubble  memory  to  the  controller  memory 
during  a  read.    This  routine  was  written  in 
assembly  language  in  order  to  achieve  a  data 
transfer  rate  of  16  K  bytes  per  second  im- 
posed by  the  bubble  memory  hardware. 

bubnv.s 

bubnriteO 

Takes  care  of  the  actual  transfer  of  data  to 
the  bubble  memory  from  the  controller 
memor\"  during  a  write.    This  routine  was 
written  in  assembly  language  in  order  to 
achieve  a  data  transfer  rate  of  16  K  bytes  per 
second  imposed  by  the  bubble  memory 
hardware. 

bubnv.s 

bubxferO 

Part  of  the  sequence  of  steps  necessary  to 
initialize  the  bubble  memory-  entails  trans- 
ferring the  byte  O.xff  to  the  bubble  memory 
40  times.   This  routine  does  this.   The  rou- 
tine is  written  in  assembly  language  for 
speed,  but  is  called  m  the  same  manner  as  a 
C  routine. 

clock.c 

clockcompareO 

Compares  two  clock  times  to  see  which  one 
is  later  than  the  other. 

clock.c 

clockintO 

Dates  and  times  in  the  real  time  clock  are 
stored  in  BCD  format.  This  routine  converts 
them  to  integer  format  to  make  it  convenient 
to  perform  arithmetic  with  them.   Thus,  fu- 
ture dates  and  times  can  be  computed. 
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clock.c 

clockreadO 

Reads  the  current  date  and  time  from  the 
real  time  clock. 

clock.c 

clocksetQ 

Sets  the  current  date  and  time  in  the  real 
time  clock  according  to  values  specified  by 
the  user. 

clock.c 

clocksumO 

.Adds  two  dates  and  times  together  to 
produce  a  new  date  and  time.    In  practice, 
one  uses  this  to  calculate  a  future  date  and 
time  from  the  current  date  and  time  and 
some  desired  delay  (e.g.,  15  minutes). 

clock.c 

dump_clock() 

Display  the  date  and  time  on  the  terminal. 

clock.c 

dump_iclock() 

Display  the  date  and  time  on  the  terminal. 
This  dilTers  from  dump_clock()  in  that  the 
dates  and  times  it  uses  are  integers,  not  Bi- 
nary Coded  Decimal  (BCD)  numbers. 

clock.c 

i:et_time() 

Obtain  a  valid  date  and  time  from  the  user. 

clock.c 

rtc() 

.-\  menu  routine  allowing  the  user  to  set  or 
read  the  clock,  and  to  test  the  time-out  fea- 
ture (see  testtimeoutO  in  this  table). 

clock.c              1  sho\\_\\aketinie( ) 

Dl'^pla\■s  the  date  and  time  when  a  time-out 
will  end. 

clock.c 

testtimeoutO 

Lets  the  u'^er  test  the  tinie-out  feature.    For 
example,  he  can  request  a  delay  of  15  sec- 
onds.   During  thi<;  delay,  the  control  pro- 
gram will  not  respond  to  input.   .At  the  end 
of  this  period,  it  uiU  display  the  current  date 
and  time. 

clock.c 

timeoutO 

In  one  mode  of  operation,  this  function 
computes  a  "wake-up"  time  based  on  the 
current  time  and  a  specified  delay.    In  an- 
other mode,  it  checks  to  see  if  a  "wake-up" 

time  computed  earlier  has  arrived  or  not. 

convert.c 

atohO 

Converts  an  .ASCII  string  representation  of 
a  hexadecimal  byte  into  the  corresponding 
hexadecimal  byte.    For  example,  the  string 
"a3"  is  converted  to  the  byte  value  Oxa3. 

convert. c 

atohexintQ 

Converts  a  four-byte  ASCII  string  repres- 
enting a  two-byte  hexadecimal  word  into  the 
corresponding  hexadecimal  word.    For  ex- 
ample, the  string  "a34b"  is  converted  to  the 
word  Oxa34b. 

convert.c 

atoi() 

Converts  a  string  representing  a  decimal  in- 
teger into  the  corresponding  integer.   This 
subroutine  is  from  Bilofsky  [Ref  18]. 
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convert. c 

bcd_asc() 

Converts  a  BCD  byte  to  the  corresponding 
character  string  representation.    For  exanv 
pie,  0x17  is  converted  to  "•17". 

convert.c 

bcdJntO 

Converts  a  one-byte  BCD  number  to  integer 
format. 

convert.c 

ctohO 

Converts  a  single  character  to  its 
hexadecimal  ASCII  string  representation. 
For  example.  Oxa3  is  converted  to  "a3". 

convert.c 

int_bcd() 

Converts  an  integer  in  the  range  0  through 
99  to  BCD  format. 

convert.c 

itoaO 

Converts  an  integer  to  an  ASCII  string  rep- 
resentation. This  subroutine  is  from  Bilofskv 
[Ref  18]. 

convert.c 

tolowerO 

Converts  upper  case  characters  to  lower 
case.    Non-alphabetic  characters  are  not 
chaneed.    This  subroutine  is  from  Bilofskv 
[Ref  ^18). 

convert.c 

uitohO 

Converts  an  unsigned  integer  to  the  corre- 
sponding hexadecimal  ASCII  string  repre- 
sentation.   For  example.  45  is  converted  to 

••:d" 

delay. s 

delayO 

Provides  a  softwarc-dnven  time  delay  m  in- 
crements of  11.)  ms.    Written  in  assembly 
language,  but  used  like  a  C  language  routine. 
.Adapted  from  a  program  by  Mr.  David 
Rigmaiden  of  the  Naval  Postgraduate 
School. 

expmnt.c 

ad_read() 

Gets  a  character  of  data  from  the  Analog- 
to-digital  (.*\  D)  Converter. 

expmnt.c 

adtointO 

Converts  a  character  of  raw  data  from  the 
Analog-to-digital  (A  D)  Converter  into  an 
integer  format  with  the  more  meaningful 
units  of  volts  or  degrees  kelvin. 

expmnt.c 

alter_pageO() 

Permits  the  user  to  alter  the  contents  of  page 
0  of  the  bubble  memory.   This  is  required  in 
initializing  the  experiment. 

expmnt.c 

bad_idea_to_record() 

This  routine  is  used  in  the  abridged  exper- 
iment to  prevent  record  mode  from  being  re- 
started after  a  power  fault.    Without  this 
safeguard,  perfectly  good  data  recorded  dur- 
ing launch  might  be  erased. 

expmnt.c 

baro_switch() 

Checks  to  see  if  the  barometric  switches  have 
been  activated  yet.   If  so,  launch  must  have 
occurred  and  an  appropriate  log  entr\-  is 
made. 

expmnt.c 

checkprtO 

Checks  to  see  whether  or  not  there  is  a  ter- 
minal connected  to  the  RS-232C  serial  inter- 
face port. 

expmnt.c 

colder_thanO 

Returns  the  value  TRUE  if  the  bubble 
memory's  temperature  is  below  the  temper- 
ature given  in  the  argument  to  the  function, 
FALSE  otherwise. 

expmnt.c 

display_data_page() 

Displays  the  contents  of  any  page  in  the 
bubble  memory  in  a  readable  format.    It  will 
not  successfully  display  page  0.    Use 
display_pageO()  for  this  purpose. 

expmnt.c 

display_pageO() 

Displays  the  contents  of  page  0  in  a  readable 
format. 

expmnt.c 

do_s"eep() 

Causes  the  sweep  phase  of  the  experiment  to 

be  performed. 

expmnt.c 

expmnti ) 

Cau'<es  the  X'ibro-acoustic  Experiment  to  be 
performed. 

expmnt.c 

listen!) 

Li<;tens  for  the  .Auxiliary  Power  Units 
(.APUs)  to  be  activated.    It  also  monitors  the 
Vibration-activated  Launch  Detector  and 
the  Barometric  Pressure  Sultches  to  sec  if  a 
launch  has  occurred  without  detection  of  the 
activation  of  the  APUs. 

expmnt.c          {  logeventl ) 

Makes  entries  into  the  event  log  stored  in  the 

b'.ibble  nieinorv. 

expmnt.c             I()g_menu() 

Displays  a  menu  to  provide  for  conveniently 
changing  the  contents  of  bubble  memorv. 
This  is  essential  for  properly  initiating  the 
experiment. 

i 
expmnt.c              monitor_heaters() 

Operates  the  heaters  if  the  temperature  of 
the  bubble  memory  is  too  cold.    If  the  tem- 
perature is  too  hot.  it  shuts  the  heaters  otT. 
Otherwi<^e  it  leaves  the  heaters  alone. 

expmnt.c 

postJaunchO 

Conducts  routine  monitoring  of  events  upon 
the  completion  of  the  Vibro-acoustic  Exper- 
iment.   These  functions  continue  until  the 
Space  Shuttle  returns  to  earth,  or  until  the 
lOV  bus  no  longer  carries  sufficient  voltage 
for  safe  operation  of  the  bubble  memories. 
In  the  latter  case,  the  experiment  stops  all 
operations. 

expmnt.c 

recordO 

Performs  the  record  phase  of  the  abridged 
experiment. 

expmnt.c 

short_experiment() 

Performs  the  abridged  Vibro-acoustic  Ex- 
periment. 

expmnt.c 

sho>v_event() 

Converts  an  event  code  into  an  intelligible 
message  which  it  then  displays  on  the  termi- 
nal. 

expmnt.c 

shut_do>vn() 

Removes  power  from  any  subsystems  which 
presently  have  power.   It  makes  a  log  entry 
for  each  such  case. 

expmnt.c 

shut_do>vn_no_log() 

Removes  power  from  any  subsystems  which 
presently  have  power.    It  makes  no  log  entry 
of  its  actions. 

expmnt.c 

ssdrmodeO 

Issues  commands  to  the  Solid  State  Data 
Recorder  (SSDR)  to  enter  various  modes  of 
operation. 

expmnt.c 

ssdr_status() 

Obtains  the  status  code  from  the  Solid  State 
Data  Recorder  (SSDR). 

expmnt.c 

voltagesJo>>() 

Checks  the  lOV  bus.   If  the  voltage  has  fallen 
too  low,  this  function  returns  the  value 
TRUE;  otherwise  it  returns  the  value 
F.ALSE. 

expmnt.c 

ne_launclied() 

Checks  for  any  indications  of  a  launch. 
These  can  come  from  the  Vibration-activated 
Launch  Detector  or  from  the  Barometric 
Pressure  Switches. 

fputc.c 

fputcO 

The  UN  I  WARE  compiler  provides  the 
standard  C  output  routine  printf()  to  provide 
output  to  the  standard  output  device.    How- 
ever, this  routine  requires  the  user  to  provide 
a  routine  fputc()  to  handle  the  output  of  a 
single  character  to  any  arbitrar\-  device.    We 
only  support  output  by  fputc()  to  the 
RS-232C  terminal,  so  this  routine  is  specific 
to  that  device.   The  routine  will  noi  output 
a  character  if.  upon  checking,  it  finds  there 
is  no  terminal  attached  to  the  serial  interface 
port.   Thus,  when  the  experiment  is  operat- 
ing, calls  to  printfO  are  of  no  effect  unless 
there  is  a  terminal  connected. 

initial.c 

inithard>vare() 

Initializes  the  six  ports  on  NSC810A  #1  and 

U2. 

inout.c 

alIow_ctrl_interrupts() 

Processes  the  special  characters  CTRL  S  and 
CTRL  Y  when  read  from  the  keyboard. 
CTRL  S  is  a  toggle  switch.    The  first  time  it 
is  pressed,  the  display  halts.  The  second  time 
it  is  pressed,  the  display  resumes.    Subse- 
quently its  function  alternates  between  these 
two.   CTRL  Y  invokes  the  diagnostic  sub- 
system. 
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inout.c 

dump!) 

Produces  a  hexadecimal  and  .-\SCII  dump 
of  anv  desired  reaion  ofmemorw 

inout.c                 echo( ) 

Sends  a  sinsle  character  to  the  termjnal. 

inout.c 

gethexO 

Inputs  a  string  representation  of  a  two-digit 
hexadecimal  number  from  the  terminal  and 
converts  it  to  hexadecimal  format.    For  ex- 
ample. "3a"  is  converted  to  Ox3a. 

inout.c 

gethexintQ 

Gets  a  four-digit  hexadecimal  number  in 
string  format  from  the  terminal  and  converts 
it  to  a  hexadecimal  word.    For  example, 
"3ab2"  is  converted  to  Ox3ab2. 

inout.c                 getinto 

Inputs  a  string  representation  of  a  decimal 
integer  from  the  terminal  and  converts  it  to 
integer  format.    For  example.  '■352"  is  con- 
verted to  352, 

inout.c              1  getpagenoO 

Asks  the  user  for  a  page  number  in  bubble 
memory. 

inout.c              1  look_ahead() 

This  program  can  see  whether  a  character 
has  been  input  from  the  keyboard  without 
disturbing  the  input  butler. 

inout.c                  portdumpi  i 

Outputs  a  string  to  the  terminal,    interface 
port. 

inout.c              1  termini ) 

Inputs  a  single  character  Irom  the  terminal. 

inout.c              '  testinpuK  ) 

.Asks  the  user  for  a  hexadecimal  port  address. 
reads  that  port  and  displays  the  data  read 
from  that  port. 

inout.c               ;  testoutputO 

.Asks  the  user  for  a  hexadecimal  port  address 
and  a  hexadecimal  byte  to  be  sent  to  the 
port,  and  '^ends  it  there. 

main.c                  main() 

First  C  language  subroutine  to  get  control 
after  start-up.    Decides  whether  to  in',  oke 
the  menu-driven  diagnostic  routines  or  to 
run  The  Vibro-acoustic  Experiment. 

mbrk.s 

mbrkO 

Implements  the  C  language  standard  librarv- 
function  mbrk().   This  function  was  provided 
with  the  Uniware  C  Compiler. 

main.c 

memory_dump( ) 

.Asks  the  user  for  an  address  in  memory  and 
the  number  of  bytes  he  wants  to  see  dis- 
played.   It  then  provides  a  hexadecimal  and 
.ASCII  display  of  the  contents  of  the  selected 
area  of  memory  on  the  terminal. 

main.c 

menuO 

Displays  the  first  in  a  hierarchy  of  menus 
permitting  the  user  to  test  subsystems  of  the 
\'ibro-acou^tic  Experiment  individually. 

main.c 

testioO 

This  routine  permits  the  user  to  perform  in- 
put from  and  output  to  any  port  in  the  sys- 
tem.   By  "port"  we  mean  here  an  address  in 
the  input  and  output  space. 

ne^vio.s 

inputO 

Inputs  a  character  from  a  port.    Written  in 
assembly  language,  but  used  like  a  C  lan- 
guage routine. 

nenio.s 

outputO 

Outputs  a  byte  to  a  port.   Written  in  assem- 
bly language,  but  used  like  a  C  language 
routine. 

power.c 

po>ver_status() 

Inputs  the  one-byte  status  code  from  the 
power  relay  subsystem. 

poAver.c 

power_>vrite() 

Sends  a  one-byte  command  code  to  the 
power  relay  subsystem. 

power.c 

pnrcntO 

A  menu  program  which  let's  the  user  read 
the  status  code  from  the  power  relay  subsys- 
tem or  send  commands  to  it. 

version.c 

version! ) 

Displays  the  current  version  number  of  the 
control  program  on  the  terminal. 
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APPENDIX  G.     CONTROL  PROGRAM  DOCUMENTATION 

We  presented  a  general  description  of  the  software  as  a  whole  in  Chapter 
IV.  DESIGN  OF  THE  CONTROL  SOFTWARE  on  page  43.  This  included  a  mod- 
erately detailed  description  of  the  flowcharts  which  describe  the  system,  beginning  with 
Flowchart  0  in  Figure  20  on  page  4S.  This  appendix  contains  more  detailed  de- 
scriptions of  the  operation  of  each  subroutine  in  the  control  program.  A  basic  know- 
ledge of  the  C  programming  language  is  assumed. 

We  have  grouped  the  functions  into  two  broad  categories: 

1.  major  subroutines,  and 

2.  support  subroutines. 

The  descriptions  m  this  appendix  are  best  understood  by  referring  to  the  source  code  in 

APPENDIX  II.     CONTROL  PROGR.-Wl  SOURCE  CODE  on  page  150. 

In  Section  A.     Major  Subroutines  and  Functions  on  page  lOS  we  present  the  major 

subroutines  and  functions  ol'  the  control  program  in  an  order  based  roughly  on  their 

position  in  the  hierarchy  of  function  calls.     This  section  therefore  follows  the  overall 

structure  of  the  control  program. 

Referring  again  to  Flowchart  0  in  Figure  20  on  page  48.  we  see  that  the  control 

program  contams  two  major  parts: 

L   One  performs  the  Vibro-acoustic  Experiment. 

2.   The  other  operates  a  menu-driven  system  to  permit  testing  of  the  system  on  the 
ground. 

Once  we  have  discussed  the  major  subroutines,  there  will  remain  numerous  lesser 
subroutines  which  we  descnbe  in  Section  B.  Supporting  Subroutines  and  Functions  on 
page  121.  We  provide  two  tables  to  make  it  easier  quickly  to  ascertain  the  purpose  of 
subroutines  and  their  locations  in  several  different  source  files.  Table  8  on  page  91  Usts 
all  subroutines  by  name,  and  shows  in  which  MS  DOS  source  files  subroutines  are  lo- 
cated. Table  9  on  page  99  lists  the  contents  of  each  MS/DOS  source  file  in  alphabetic 
order  by  name. 

In  general,  the  program  attempts  to  display  many  diagnostic  messages  on  the  ter- 
minal using  the  printfO  function.  This  function  was  supplied  with  the  C  compiler,  but 
It  in  turn  calls  a  function  called  fputc()  not  supplied  with  the  compiler.    The  purpose  of 


the  subroutine  fputc()  is  to  accept  a  character  from  the  printf()  function  and  to  send  it 
to  the  terminal  for  display.  We  created  this  subroutine,  and  its  description  is  contained 
in  Section  B.  Supporting  Subroutines  and  Functions  on  page  121.  This  function  al- 
ways checks  to  see  whether  there  is  a  terminal  attached  or  not.  If  not,  it  makes  no  at- 
tempt to  display  any  messages  on  the  terminal.  Henceforth,  whenever  we  say  that 
something  will  appear  on  the  terminal,  it  will  be  understood  that  this  will  only  occur  if 
the  terminal  is  attached. 

A.     MAJOR  SUBROUTINES  AND  FUNCTIONS 

1.     main() 

This  is  the  beginning  point  for  any  C  language  program.  It  is  called  by  the 
start-up  code,  which  is  written  in  Z-SO  assembly  language.  The  main()  program  first 
initializes  pointers  to  the  bulTers  which  will  hold  data  from  the  bubble  memor\-.  There 
are  two  formats  for  such  data.  One  is  used  in  page  zero  of  the  memon.-.  which  is  used 
to  record  the  current  status  of  the  experiment.  The  other  format  is  used  in  all  other 
pages  of  the  bubble  memory  to  record  all  actions  and  measurements  taken  during  the 
experiment.  The  buflers  are  treated  both  as  arrays  and  as  structures.  When  they  are 
treated  as  arrays,  it  is  easy  to  transfer  the  data  to  or  from  the  bubble  memory.  When 
they  are  treated  as  structures,  it  is  easy  to  extract  individual  fields  of  data.  By  forcing 
the  pointers  pagezero  and  iog_page  to  point  to  the  arra\s  pageO_l)ufTer  and  log_buffer 
respectively,  we  can  access  the  data  subsequently  by  using  either  the  pointer  to  the 
structure  or  the  name  of  the  array  as  appropriate. 

The  niainO  program  then  calls  inithardwareO  to  initialize  the  two  NSC810A 
R.-\M-I  O  Timer  chips  on  the  controller  board.  Next  it  checks  to  see  if  there  is  a  ter- 
minal attached  by  calling  checkprt().  The  absence  of  a  terminal  implies  that  the  appa- 
ratus is  now  installed  in  the  Space  Shuttle  and  the  controller  should  therefore  perform 
the  experiment.  Therefore,  if  there  is  no  terminal  attached,  main()  will  call  expmnt(), 
which  performs  the  Vibro-acoustic  Experiment. 

If  there  is  indeed  a  terminal  attached,  main()  calls  shut_down_no_log(),  whose 
function  is  to  remove  power  from  all  subsystems  without  logging  that  action  in  the 
bubble  memor\'.  The  reason  for  removing  power  is  to  ensure  that  all  the  subsystems  are 
in  a  known  state  at  the  outset.  The  reason  for  not  wishing  to  log  this  action  is  that  the 
log  entries  should  only  be  made  during  the  course  of  the  experiment.  Since  the  con- 
troller is  about  to  enter  the  menu  subsystem,  it  is  not  going  to  perform  the  experiment 
and  so  no  log  entr}-  is  appropriate. 


Next  maiiiO  calls  menuQ.  from  which  all  other  testable  sections  of  the  control 
program  can  be  selected.    The  option  EXPERIMENTOK  permits  the  menu  diagnostic 
subsystem  to  invoke  the  program  e.\pnint()  later,  if  the  user  wishes  to  do  so.   This  would 
permit  him  to  perform  the  experiment  on  the  ground  and  so  test  its  operation. 
2.     void  inithard\vare(void) 

This  subroutine  initializes  the  two  NSC810A  R.-\M-I  O-Timer  chips  on  the 
controller  board.  The  uses  of  the  pins  of  port  A  in  each  chip  are  given  in  Table  A  on 
page  17  and  Table  5  on  page  17;  those  of  Port  B  are  given  in  Table  2  on  page  15  and 
Table  3  on  page  16:  and  those  of  port  C  are  given  in  Table  6  on  page  18  and  Table  7 
on  page  19. 

MDRl  is  the  .Mode  Definition  Register  of  the  NSC810A  -1.  Writing  a  0x00  to 
It  puts  port  A;  into  basic  I  O  mode,  which  is  the  simplest  method  oi'  1  O  supported  by 
this  chip.-- 

DDRAl  IS  the  Data  Direction  Register  of  port  .A,  of  the  NSCSlo.A  =1.  Writing 
O.xfTto  it  causes  each  of  its  bus  to  be  configured  for  output. 

DDRBl  :s  the  Data  Direction  Register  of  port  B,  of  the  NSCSlCtA  =1.  Writing 
O.xiTto  It  causes  each  of  its  bits  to  be  configured  for  output. 

DDRCl  IS  the  Data  Direction  Register  of  port  C,  of  the  NSCSlO.A  =1.  Writing 
0x30  to  it  causes  bits  0  through  3  and  bits  6  and  ~  to  be  configured  for  input.  Bits  4  and 
5  are  configured  for  output,  although  bit  5  is  not  used  in  the  Vibro-acoustic  Experiment. 
Note:    this  is  only  a  6  bit  port:  bits  6  and  ^  do  not  exist. 

TMOf  is  the  register  for  setting  the  mode  of  Timer  0  in  NSCSIOA  s^l.  Writing 
O.xOO  to  it  will  stop  the  tim.er.  an  action  which  must  be  performed  before  changing  its 
mode.  Writing  0x25  will  cause  the  timer  to  produce  a  square  wave  without 
■■prescaling"  and  with  "single  precision".  When  prescaling  is  not  used,  every  pair  of  in- 
put clock  cycles  is  used  to  advance  the  timer's  counter  by  one.  When  single  precision 
is  selected,  only  the  low  byte  of  the  timer  will  ever  be  read. 

TOLBl  and  TOHBl  are  the  registers  for  the  low  byte  and  high  byte  respectively 
of  the  modulus  for  Timer  0  in  NSC810  =1.  This  number  serves  to  initiate  the  timer 
counter.  During  subsequent  operation,  the  counter  is  decremented  once  even,  clock 
period.  Each  time  the  counter  reaches  0,  the  timer  output  switches  to  the  opposite  state 
and  the  timer  is  reloaded.  We  write  0x07  to  the  low  byte  and  0x00  to  the  high  byte,  so 
the  modulus  is  7.    This  means  that  after  ever}'  seven  cycles,  the  clock  is  reloaded.    The 


22  With  basic  I  O.  there  is  no  handshaking  (see  Glo5sar>)  with  support  hardware. 
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reloading  consumes  a  further  cycle,  and  it  takes  two  complete  reloads  to  go  through  one 

cycle  of  the  output.    The  period  thus  is  2  x  (7  +  1)  =  16  clock  periods.    The  NSCSOO  is 

driven  by  a  4.9152  h-  2  =  2.4576  MHz  clock.    So  16  clock  periods  take  6.51    ^s,  for  a 

clock  frequency  of-r-TT =  153.6  kHz.    This  signal  is  used  as  a  baud-rate  generator 

6.51  ^^s 
on  the  controller  board;  it  is  fed  to  an  Intersil  6402  UART  which  further  divides  the 

frequency  by  16,  yielding  a  9600  baud  transmission  rate  at  which  to  drive  the  RS-232C 

interface. 

STARTOi  is  the  start  port  of  Timer  0  in  NSC810  #1.  Writing  anything  to  this 
port  causes  the  newly  programmed  timer  to  start  operating. 

MDR2  is  the  Mode  Definition  Register  of  the  NSC810A  ^2.  Writing  a  0x00  to 
it  puts  port  A,  into  basic  I  O  mode.  This  is  the  simplest  method  of  1  O  supported  by 
this  chip. -3 

DDR.-\2  is  the  Data  Direction  Register  of  port  A,  of  the  NSC810A  -2.  Writing 
0x00  to  it  causes  each  of  its  bits  to  be  configured  for  input. 

DDRB2  is  the  Data  Direction  Register  of  port  Bj  of  the  NSC810A  ^^2.  Writing 
0x00  to  it  causes  each  of  its  bits  to  be  configured  for  input. 

DDRC2  is  the  Data  Direction  Register  of  port  C^  of  the  NSC810A  #2.  Writing 
0x31  to  it  causes  bits  1  through  3  to  be  configured  for  input.  Bits  0,  4  and  5  are  con- 
figured for  output.  Bits  1  and  2  are  not  in  use.  Note:  this  is  only  a  6  bit  port;  bits  6 
and  7  do  not  exist. 

TMo2  is  the  register  for  setting  the  mode  of  Timer  0  in  NSC810A  ~2.  Before 
you  can  change  the  mode,  you  must  first  stop  the  timer.  Writing  0x00  to  it  does  this. 
Writing  0x25  will  cause  the  timer  to  produce  a  square  wave  without  "prescaling"'  and 
with  "single  precision".  When  prescaling  is  not  used,  every  pair  of  input  clock  cycles  is 
used  to  advance  the  timer's  counter  by  one.  When  single  precision  is  selected,  only  the 
low  byte  of  the  timer  will  ever  be  read. 

T0LB2  and  T0HB2  are  the  registers  for  the  low  byte  and  high  byte  respectively 
of  the  modulus  of  Timer  0  in  NSC810  U2.  This  number  serves  to  initiate  the  timer 
counter.  Once  ever}'  clock  period,  the  counter  is  decremented.  Each  time  the  counter 
reaches  0,  the  timer  output  switches  to  the  opposite  state  and  the  timer  is  reloaded. 
We  write  0x0 1  to  the  low  byte  and  0x00  to  the  high  byte,  so  the  modulus  is  1.  This 
means  that  after  1  cycle,  the  clock  is  reloaded.  Now  the  reloading  consumes  a  further 
cycle,  and  it  takes  two  complete  reloads  to  go  through  one  cycle  of  the  output.    The 


23  With  basic  1,0,  there  is  no  handshaking  (see  Glossary)  with  support  hardware. 


period  thus  is  2  x  (1  +  1)  =  4  clock  periods.  The  NSC800  is  driven  by  a 
4.9152  ^  2  =  2.45"6  MHz  clock.  So  4  clock  periods  take  1.628  us.  for  a  clock  frequency 
0^  1  o^S  us  ^  ^'^"'■"'  ^^^^"  ^^^^  frequency  is  used  as  a  clock  for  the  National  Semicon- 
ductor ADC0S16  Analog-to-digital  (A  D)  Converter. 

When  driven  by  a  clock  of  frequency  640  kHz,  the  A  Ds  normally  can  complete 
the  conversion  of  an  analog  signal  to  a  digital  value  in  around  100  ^s.  The  frequency 
we  are  using  here.  614.4  kHz.  is  close  to  this,  so  we  should  get  comparable  performance. 
[Ref  19:  pp.  S-"l  to  S-81] 

START02  is  the  start  port  for  Timer  0  in  NSC810  U2.  Writing  anything  to  this 
port  causes  the  newly  programmed  timer  to  start  operating. 

Finally,  we  clear  bits  4  and  5  of  port  Q  by  writing  0x03  to  the  port  C^ 
"bit  clear"  register.  BCLRC2.  The  purpose  of  this  is  to  ensure  that  power  to  the  bubble 
memory  remains  ofT,  and  to  ensure  that  the  bubble  memorv's  reset  line  is  held  low. 
Strictly  speaking,  this  should  not  be  necessar\-,  since  the  registers  of  the  NSCSIO  are  in- 
itialized to  be  zeros.  However,  we  take  nothing  for  granted,  and  this  precaution  helps 
preclude  the  loss  of  the  bubble  memory's  contents  that  might  result  from  an  improper 
application  of  power. 

3.  char  checkprt(void) 

This  function  inspects  the  TERMON  bit  (bit  3)  of  Port  C  in  NSCSIO  ^^2.  This 
bit  IS  a  0  if  there  is  an  RS-232C  terminal  connected  to  the  controller.  It  is  a  1  other\vise. 
The  function  returns  a  TRUE  in  the  first  case;  a  FALSE  in  the  second. 

4.  void  sliut_donn_no_Iog(void) 

This  subroutine  removes  power  from  any  subsystems  which  are  currently  on. 
It  does  not  record  the  fact  in  the  bubble  memon.'  log.  which  is  the  only  respect  in  which 
it  differs  from  the  subroutine  shut_do\\nO.  It  obtains  a  character  describing  the  position 
of  each  of  the  relays  in  the  power  subsystem  by  calling  the  function  po^ver_status().  The 
series  of  if  statements  which  then  follows  causes  successive  bits  of  that  character  to  be 
tested.  Even-  time  one  of  these  bits  indicates  that  a  relay  is  in  the  'on'  position,  that 
relay  is  turned  off  with  a  call  to  po>^er_>vrite(). 

5.  char  menu(char  experiment_nag) 

This  function  is  at  the  top  of  a  hierarchy  of  diagnostic  subroutines.  The  func- 
tion calls  the  sub-function  versionQ  whose  only  purpose  is  to  display  the  number  and 
date  of  the  current  version  of  the  control  program.  It  next  presents  a  menu  from  which 
the  user  can  select  any  of  a  number  of  categories  of  diagnostic  tests.  The  function 
terminO  is  used  to  obtain  a  single  character  from  the  keyboard,  that  character  is  con- 


verted  to  lower  case  by  tolo>ver()  (if  it  was  not  already  in  lower  case),  and  the  character 
is  displayed  on  the  terminal.  That  character  is  used  by  the  switch  to  select  a  case  state- 
ment appropriate  to  the  user's  choice.  The  entire  process  will  be  executed  repetitively. 
The  only  way  to  leave  it  is  by  choosing  to  run  the  experiment.  If  this  is  done,  the 
function  expmnt()  gets  control. 

To  cause  a  software  reset,  the  program  executes  an  assembler  instruction  jp  0. 
This  function  has  the  effect  of  restarting  the  controller  at  address  0  of  memor\-.  This  is 
the  same  address  at  which  execution  begins  when  power  is  first  applied.  All  variables 
are  set  to  their  initial  values,  other  start-up  functions  are  performed  as  usual,  and  the 
program  main()  begins  to  execute  anew. 

The  function  rtc()  accesses  the  real-time  clock  diagnostic  subroutines. 

The  function  p\\rcnt()  access  the  power  subsystem  diagnostic  subroutines. 

The  function  bubmenu()  accesses  the  diagnostic  subroutines  which  can  be  used 
to  test  the  bubble  memory  module.  The  tests  available  through  this  selection  all  are  ver>' 
low-level  tests. 

When  choice  E  is  made,  the  controller  enters  a  for  loop  and  successively  reads 
each  of  the  analog-to-digital  {A  D)  converter  channels  by  calling  the  sub-function 
adread{).  This  function  returns  an  eight-bit  number  addata  which  is  proportional  to  the 
value  read  by  the  A  D  converter.  A  call  to  printf()  displays  this  number  along  with  a 
descriptive  adcaption  (defined  in  the  file  global. c).  The  first  three  readings  are  known  to 
be  voltages.  The  remaining  values  are  temperatures,  so  they  are  displayed  in  a  slightly 
different  format.  Furthermore,  depending  on  which  channel  the  A  D  converter  read,  the 
number  read  may  represent  different  magnitudes  in  the  measured  units.  For  example, 
the  number  102  may  represent  4V  or  270°  K,  depending  on  which  channel  was  read. 

Voltages,  fall  either  into  the  range  [0,  10]V  or  the  range  [0,  20]V.  Temperatures 
fall  into  the  range  [0,  500]°  K.  The  function  adtoint()  converts  the  value  read  by  the  AD 
converter  into  its  value  in  degrees  Kelvin  or  in  hundredths  of  volts,  whichever  is  appli- 
cable. The  converted  value  is  then  displayed  using  the  printf()  function.  To  get  two 
converted  readings  per  line,  carriage  returns  are  placed  at  the  end  of  ever>'  other  dis- 
played value,  only. 

There  are  two  possibiUties  if  choice  F  is  made.  One  is  that  experiment_flag  is 
TRUE;  the  other  is  that  it  is  FALSE.  The  former  case  always  occurs  when  menu()  is 
called  the  first  time,  from  mainQ.  However,  it  is  possible  to  interrupt  the  execution  of 
the  experiment  and  to  enter  the  menu  subsystem  recursively.    It  is  not  possible  to  make 


menu  choice  F  under  these  circumstances.  To  restart  the  experiment  would  require  first 
making  choice  A  to  reset  the  system. 

The  function  testio()  is  called  when  choice  G  is  made.  Its  purpose  is  to  allow 
low-level  testing  of  the  peripheral  devices. 

The  function  memory_dump()  is  called  when  choice  H  is  made.  Its  purpose  is 
to  display  the  contents  of  the  controller's  memor\-.  This  is  useful  only  in  debugging  the 
software. 

The  function  log_menu()  is  called  when  choice  I  is  made.  Its  purpose  is  to  allow 
the  contents  of  the  bubble  memory  to  be  displayed.  It  diflers  from  the  functions  called 
when  choice  D  is  made  in  that  the  contents  of  the  bubble  memory  are  regarded  by 
log_nienu()  as  formatted  data  areas,  not  just  as  collections  of  characters.  This  means 
that  the  data  stored  in  the  bubble  memory  during  execution  of  the  experiment  can  be 
displayed  in  an  intelligible  format,  and  the  experiment's  status,  stored  in  page  0.  also  can 
be  displayed  in  a  readable  format.  The  function  log_menu()  also  allows  the  status  to  be 
modified  in  order  to  aiTect  the  manner  in  which  the  controller  performs  the  experiment. 
The  details  of  how  to  do  this  are  contained  in  Chapter  V.  HOW  TO  GET  THE  EX- 
PERIMENT READY  FOR  A  LAUNCH  on  page  63. 

6.  void  version(void) 

This  function  displays  the  number  and  date  of  the  current  version  of  the  control 
program  on  the  terminal. 

7.  void  rtc(void) 

This  function  displays  a  menu  of  functions  related  to  the  operation  of  the  real- 
time clock.  The  clock  can  be  read,  set  or  tested  from  here.  The  method  of  displaying 
the  menu,  reading  the  choice,  and  taking  the  appropriate  action  is  identical  to  that  used 
in  the  function  menuQ  described  earher.  The  function  rtcQ  differs  only  in  the  choices 
and  actions  possible. 

Choice  A  causes  the  function  clockreadO  to  be  called.  It  stores  the  current  date 
and  time  in  a  structure  whose  pointer  is  clock.  The  function  dump_clockO  is  called  next; 
it  displays  the  date  and  time  on  the  terminal.  This  choice  is  provided  to  verify  that  the 
real  time  clock  is  working  correctly. 

Choice  B  causes  the  function  clockset()  to  be  called.  It  permits  the  user  to  set 
the  current  date  and  time.  The  real  time  clock  is  powered  by  its  own  batten.-,  so  this 
option  should  seldom  be  required. 


Choice  C  causes  the  function  testtimeout()  to  be  called.  Its  purpose  is  to  permit 
the  operation  of  the  timeout  feature  to  be  tested.  It  is  useful  only  in  debugging  the 
software. 

8.  void  clockread(struct  datetime  *your_clock.) 

This  function  inputs  the  binary-coded-decimal  (BCD)  time  from  the  real-time 
clock  and  places  the  results  in  a  structure  pointed  to  by  your_cIock.  If  the  current 
number  of  seconds  changes  between  the  start  and  end  of  reading,  it  means  that  the  clock 
has  advanced  to  a  subsequent  time.  To  preclude  the  reading  of  an  incorrect  time,  the 
input  sequence  is  repeated  in  the  hope  that  an  advance  will  not  occur  again.  This  can 
happen  up  to  10  x  TRIES  times. 

For  example,  suppose  the  time  were  9:59:59  when  the  seconds  and  minutes  were 
read.  The  clock  might  advance  to  10:00:00  before  the  hours  were  read.  Then  the  time 
read  would  appear  to  be  10:59:59.  which  is  wrong  by  one  hour.  By  reading  it  again,  we 
may  avoid  this  error,  but  there  is  no  obvious  way  to  guarantee  it  without  stopping  the 
clock.  Doing  so  would  be  disadvantageous,  since  it  would  affect  timing  relationships  in 
an  unpredictable  manner,  so  we  chose  not  to  stop  the  clock  but  to  take  our  chances  and 
try  reading  it  again. 

9.  void  dump_clock(struct  datetime  *clock) 

This  function  displays  on  the  terminal  the  time  stored  in  a  structure  pointed  to 
by  clock.  To  do  this  it  calls  the  function  bcd_int().  which  converts  the  BCD  values  in  the 
date  and  time  pro\'ided  by  the  real  time  clock  into  decimal  equivalents.  These  converted 
values  are  then  displayed  by  the  function  printf(). 

10.  void  clockset( struct  datetime  *clock) 

This  function  first  calls  the  function  get_time()  to  ask  the  user  for  the  current 
date  and  time.  The  time  specified  is  left  in  the  structure  pointed  to  by  clock.  The  func- 
tion cIocksetQ  then  stores  the  date  and  time  in  the  real-time  clock  by  repeated  calls  to 
output(). 

1 1.  void  testtimeout(void) 

This  allows  the  user  to  test  that  the  time-out  function  is  working.  The  time-out 
function  enables  the  control  program  to  continue  normal  processing  while  waiting  for 
some  amount  of  time  to  elapse. 

For  example,  after  launch  the  controller  will  monitor  the  Solid  State  Date  Re- 
corder (SSDR)  for  completion  of  recording.  However,  it  will  also  initialize  a  time-out 
of  three  minutes,  and  will  stop  waiting  for  the  SSDR  if  this  time  should  elapse  before  the 
SSDR  signals  completion.  The  testtimeout()  function  allows  the  user  to  test  the  time-out 


feature  for  any  number  of  seconds,  minutes  or  hours.  A  menu  is  presented  to  the  user 
using  the  same  method  already  outlined  in  the  description  of  the  function  nienu().  The 
units  of  the  specified  delay  depends  on  the  menu  choice  made.  The  function  getint()  is 
called  to  obtain  the  number  of  units  of  delay  that  the  user  wants.  The  current  time  then 
is  obtained  with  a  call  to  clockread().  and  it  is  displayed  on  the  terminal  with  a  call  to 
dump_cIock().  The  timeout()  function  then  is  called  to  initialize  the  delay  according  to 
the  number  of  delay  units  specified  by  the  user.  A  >\hile  loop  calls  timeout()  repeatedly 
with  the  NULL  parameter.  This  parameter  causes  the  timeout()  function  to  check  to  see 
if  the  desired  wake-up  time  has  arrived  or  not.  As  long  as  it  has  not  yet  arrived,  that 
function  returns  FALSE  and  the  program  continues  to  loop.  If  other  statements  were 
provided  before  the  end  of  the  loop,  then  they  would  be  performed  repeatedly  until  the 
function  timeoutO  finally  returned  TRUE,  signifying  that  the  desired  amount  of  time  had 
elapsed.  The  function  testtimeout()  has  no  such  instructions,  but  when  the  delay  period 
is  over,  it  rings  the  bell  and  once  again  reads  and  displays  the  current  time. 

12.  void  p\\rcnt(void) 

1  his  function  displays  a  menu  to  allow  the  user  to  te'^t  the  operation  of  the 
power  board  relays.  .Any  of  the  attached  units,  such  as  the  SSDR.  can  be  switched  on 
or  off  from  this  menu.  The  method  of  displaying  the  menu  is  the  same  as  that  already 
given  in  the  description  of  the  function  menul).  Any  menu  choice  from  A  through  J  is 
converted  to  a  number  in  the  range  [0.9]  by  subtracting  the  character  'a'  from  it.  1  his 
number  is  then  used  as  an  inde.x  into  array  relay  to  select  the  command  to  be  issued  to 
the  power  control  subsystem  through  a  call  to  the  function  poner_\>rite().  Choice  K 
causes  the  power  subsystem's  status  to  be  read  with  a  call  to  po\\er_status()  and  then 
displayed  on  the  terminal.   The  meaning  of  this  byte  is  shown  in  Table  2  on  page  15. 

13.  void  bubmenu(void) 

This  function  displays  a  menu  which  lets  the  user  test  the  bubble  memor\-  on  the 
controller  circuit  board.  The  method  of  displaying  the  menu  is  the  same  as  that  already 
given  in  the  description  of  the  function  menu(). 

Choice  A  causes  a  call  to  bub_on(). 

Choice  B  causes  a  call  to  bub_offO. 

Choice  C  attemps  to  initialize  the  bubble  memor\-  with  a  call  to  bubinit(),  The 
results  of  this  attempt  are  then  explained  with  a  call  to  printf(). 

Choice  D  causes  a  call  to  bubcnidmenu(). 


Choice  E  causes  a  call  to  testpatternQ.  The  character  string  tenipbuffer  is  pro- 
vided to  this  function  for  storage  of  a  string  of  characters  entered  by  the  user  from  the 
keyboard. 

Choice  F  causes  the  contents  of  tempbuffer  to  be  displayed  in  ASCII  format. 

Choice  G  causes  the  contents  of  tempbuffer  to  be  displayed  in  hexadecimal  for- 
mat. This  would  be  useful  if  the  buffer  had  been  loaded  from  the  bubble  memory  and 
if  it  contained  unprintable  characters.  Such  would  be  the  case  if  the  contents  of  the 
bubble  memory  had  been  generated  by  performing  the  experiment,  since  the  experiment 
formats  the  data  in  characters  which  may  not  all  be  capable  of  being  displayed. 

Choice  H  calls  getpageno()  to  ask  the  user  which  page  of  the  bubble  memory 
he  wishes  to  access.  It  then  calls  bubio()  to  transfer  the  contents  of  the  buffer  into  that 
page  of  the  bubble  memory. 

Choice  I  calls  getpagenoO  to  ask  the  user  which  page  of  the  bubble  memory  he 
wishes  to  access.  It  then  calls  bubio()  to  transfer  the  contents  of  that  page  of  the  bubble 
memory  into  the  buffer. 

Choice  J  causes  a  call  to  rdstatregO,  which  reads  and  displays  the  contents  of 
the  bubble  memory  controller's  status  register.  The  format  of  this  register  is  discussed 
in  detail  in  [Ref  1]. 

14.  char  bub_on(void) 

This  function  applies  power  to  the  bubble  memory  on  the  controller  circuit 
board. 

15.  void  bub_off(void) 

This  function  removes  power  from  the  bubble  memory  on  the  controller  circuit 
board. 

16.  char  bubinit(void) 

This  subroutine  initiates  the  bubble  memory  on  the  controller  circuit  board. 
Power  must  have  been  applied  first.  The  sequence  of  commands  is  described  in 
[Ref  1:  pp.  38-39b].   It  is  as  follows: 

1.  Issue  the  BABORT  (abort)  command  to  the  bubble  memor}'. 

2.  Set  up  the  parametric  registers,  pointing  to  page  0  of  the  bubble  memory. 

3.  Issue  the  BIN  IT  (bubble  initialize)  command. 

4.  Issue  the  BFIFORESET  (bubble  FIFO  reset)  command  to  reset  the  first-in,  first- 
out  (FIFO)  buffer  in  the  controller's  bubble  memory. 

5.  Transfer  40  Oxff  characters  to  the  FIFO  buffer  in  the  bubble  memorv. 


6.    Issue  the  BWRBLREG  (bubble  write  boot  loop  register)  command.  At  this  pomt, 
the  bubble  memon  is  ready  for  reading  and  writing. 

17.  void  bubcmdmenu(void) 

This  subroutine  allows  the  user  to  issue  any  of  the  following  commands  to  the 
bubble  memon.-,  one  at  a  time: 

1.  Abort 

2.  Load  parametric  registers 

3.  Initialize 

4.  Reset  the  FIFO  buffer 

5.  Perform  the  transfer  of  40  Oxff  characters  to  the  FIFO 

6.  Write  the  boot  loop  register 

These  conimands  are  issued  by  bubinit().  but  are  provided  separately  here  to  permit  de- 
tailed testing  of  the  initialization  process. 

18.  void  testpattern(char  buffer[  ]) 

This  subroutine  permits  the  user  to  fill  a  bufTer  in  R.-\M  with  characters  to  be 
written  to  the  bubble  memor>-.  Up  to  PAGE  LENGTH  characters  can  be  written  at  a 
time.  Its  purpose  i^  to  enable  the  user  to  verify  that  data  can  be  written  to  the  bubble 
memor>-  and  read  back  successfully  later. 

This  subroutine  begins  by  placing  a  0  in  the  variable  c.  It  asks  the  user  to  enter 
a  string  of  characters  from  the  keyboard,  and  then  enters  a  loop.  It  will  continue  reading 
up  to  PAGELENGTH  characters.  If  it  encounters  a  carriage  return,  it  will  place  blanks 
in  the  remainder  of  the  buffer. 

19.  void  shonbubbuff(char  buffer[  ].  char  mode) 

This  subroutine  will  display  the  contents  of  buffer  either  in  ASCII  format  or  in 
hexadecimal  representation,  according  to  the  value  of  mode.  This  parameter  can  be  ei- 
ther ASCII  or  HEX.  The  ASCII  format  would  be  suitable  if  it  were  known  that  the 
bubble  memory  page  buffer  contained  only  printable  characters,  as  it  would  if  it  had 
been  filled  by  testpatternQ.  The  hexadecimal  format  would  be  suitable  if  it  were  known 
that  the  bubble  memor\'  page  previously  read  contained  unprintable  characters,  or  if  the 
contents  were  unknown. 24 


24  It  may  be  unwise  to  risk  sending  potentially  unprintable  characters  to  the  terminal,  smce 
some  of  them  ha\e  surprising  results,  such  as  clearing  the  screen. 
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20.  char  bubio(char  command,  int  page,  char  *buffer) 

This  subroutine  permits  reading  from  or  writing  to  any  page  of  the  bubble 
memory.  Pages  can  fall  in  the  range  0  through  8191.  Commands  can  be  either  one  of 
BREAD  or  BWRITE.  The  data  is  placed  into  or  read  from  the  buffer  pointed  to  by 
buffer. 

To  operate  the  bubble  memory  when  the  temperature  falls  below  10° C  may 
cause  its  contents  to  be  destroyed.  A  call  to  the  function  coIder_than()  precludes  this 
from  happening.  If  that  function  returns  TRUE,  then  it  must  be  too  cold.  The  function 
bubio  returns  a  FALSE  to  indicate  that  it  was  unsuccessful  in  accessing  the  bubble 
memory. 

To  minimize  power  consumption,  the  subroutine  applies  power  to  the  bubble 
memory  before  the  operation  begins  and  removes  it  again  at  the  end  of  the  transfer.  It 
calls  bpagesetQ  to  set  the  parametric  registers  so  as  to  allow  the  correct  page  of  bubble 
memory  to  be  transferred.  It  then  calls  bubread()  or  bubv>rite()  as  appropriate.  After  the 
transfer  is  coniplcted,  the  subroutine  reads  the  bubble  status  register  to  see  if  the  oper- 
ation was  successful  or  not.  The  bubioO  subroutine  returns  a  TRUE  if  the  transfer 
worked;  FALSE  other\vise. 

21.  void  rdstatreg(void) 

This  subroutine  lets  the  user  check  the  contents  of  the  bubble  memor\-  status 
register.  The  meaning  of  its  contents  is  shown  in  Table  10  on  page  119.  To  obtain  the 
status  code,  this  subroutine  calls  the  function  input(),  which  reads  the  contents  of  the 
port  BUBCTRL  (port  Ox-ll).  This  port  yields  the  status  code,  which  is  then  converted 
to  hexadecimal  format  using  the  function  ctoh()  and  is  displayed. 

22.  void  e\pmnt(void) 

This  function  performs  the  experiment.  Its  first  task  is  to  call  initialize().  This 
subroutine  retrieves  the  current  mission  status  from  page  0  of  the  bubble  memory.  If 
there  is  no  more  room  in  the  bubble  memory,  a  value  of  FALSE  v,'i\\  be  returned.  Al- 
though the  experiment  will  be  performed,  no  entries  can  be  made  in  the  log.  The  Solid 
State  Data  Recorder  (SSDR)  may  therefore  still  be  able  to  record  acoustic  data  suc- 
cessfully.  There  will  be  no  log  of  the  events  as  they  occur,  however. 

The  function  expmntQ  next  checks  to  see  whether  the  flag  full_experiment  in 
page  0  is  TRUE  or  FALSE.  If  not,  the  function  short_experiment()  is  called  to  perform 
the  abridged  experiment.  Otherwise,  the  unabridged  experiment  is  to  be  performed  by 
expmnt(). 
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Table   10.     BIT  ASSIGNMENTS  FOR  THE  BUBBLE  MEMORY  CONTROLLER 
(BMC)  STATUS  BYTE:     From  [Ref.    1  :  Chapter  3.  p.  121- 


Bit 

Value 

Meaning 

0 

1 

FIFO  Ready.   The  FIFO  bufler  is  ready 
to  transfer  data. 

0 

The  FIFO  bufTer  is  not  readv. 

1 

1 

Parity  error. 

0 

No  parity  error. 

: 

1 

l/ncorrectable  error. 

() 

No  uncorrectable  error. 

1 

Tm-ung  error. 

1) 

No  timing  error. 

4 

1 

OP  F.AIL.    The  current  operation  failed. 

0 

No  OP  r.AIL. 

5 

1 

OP  COMPLETE.  The  current  operation 
IS  complete. 

1) 

No  OP  COMPLETE. 

6 

1 

Bus\.    This  means  that  a  cominand  has 
been  accepted  but  is  not  yet  complete. 
The  BMC  stays  busy  throughout  a  data 
tran>^fer. 

0 

Not  busv. 

The  next  step  is  to  initiate  the  sweep  phase,  if  this  has  not  already  been  done. 
Recall  that  this  might  have  occurred  if  power  had  been  removed  from  the  controller  at 
an  earlier  time,  whether  by  human  intervention  or  through  a  fault.  If  the  sweep  phase 
is  required,  the  function  do_s>veep()  is  called  to  do  it. 

Next  the  controller  must  decide  whether  or  not  a  launch  has  already  occurred. 
It  consults  the  launchdone  flag  in  page  0  of  the  bubble  memor>-.  If  this  flag  is  TRUE, 
the  Space  Shuttle  launched  earlier.  Otherwise,  we  must  listen  for  the  activation  of  the 
AuxiUary  Power  Units  (APUs)  by  calling  the  function  listenQ.  When  this  function 
completes  its  job,  it  will  return  a  mission  status.  This  can  take  on  any  one  of  the  fol- 
lowing values: 
DAPUO.N  The  activation  of  the  APUs  has  been  detected. 
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DLAUNCH  The  activation  of  the  APL's  was  never  detected,  but  launch  was 

detected.  This  may  be  the  case  if  the  Vibration-activated 
Launch  Detector  detects  the  vibration  associated  with  the  ig- 
nition of  the  solid  rocket  motors  or  if  the  Barometric  Pressure 
Switches  detect  an  ascent. 

DUSERNOAPU  The  system  is  being  tested  on  the  ground  and  the  user  depressed 

a  key  while  the  system  was  hstenmg  for  the  APL's.  This  pro- 
vides a  means  of  terminating  the  period  of  waiting  for  a  signal. 

If  listenO  detects  anything,  then  the  function  expmnt()  will  turn  on  the  Analog- 
to-Digital  (AD)  Converter  by  sending  the  code  ADON  to  the  function  poner_write(). 
It  then  will  turn  on  the  Solid  State  Data  Recorder  (SSDR)  by  sending  the  code 
SSDRON  to  the  same  function.  Both  these  actions  will  be  logged  in  the  bubble  memor\' 
by  the  function  logevent().  If  listen()  had  returned  the  mission  status  code  D.-\PL'0\, 
then  e.\pmnt()  commands  the  SSDR  to  enter  scroll  mode,  which  means  that  it  will  start 
recording  ambient  noise.  Since  the  APL's  are  now  on,  we  know  that  a  launch  must  oc- 
cur within  seven  minutes,  or  the  mission  will  be  scrubbed  by  NAS.A.  We  want  to  wait 
at  least  this  long.  To  be  on  the  conservative  side,  we  begin  a  ten  minute  time-out  period, 
during  which  we  wait  for  some  indication  of  a  launch.  The  function  nejaunched()  will 
return  the  mission  status  code  DLALNCH  if  k  detects  such  an  indication.  The  function 
look_ahead_discard()  checks  to  see  whether,  during  ground  testing,  the  user  has  depressed 
a  key  during  this  time-out  period.  If  so.  we  regard  the  time-out  as  having  been  com- 
pleted. This  permits  accelerated  testing  of  the  system  without  always  waiting  for  the  end 
of  the  full  time-out  period.  Eventually  one  of  the  two  conditions  will  have  occurred  and 
the  waiting  period  will  end. 

If  the  launch  had  occurred  at  some  earlier  time,  we  would  end  up  in  the  next 
section  of  the  code  in  exprnntQ.  The  fact  that  a  launch  had  occurred  previously  would 
be  logged  by  calling  logevent()  with  the  argument  PRIORLALNCH,  and  the  mission 
status  would  be  set  to  this  same  value. 

The  next  section  of  code  is  executed  only  if  a  launch  is  in  progress.  The  SSDR 
is  commanded  to  leave  scroll  mode  and  enter  launch  mode.  The  SSDR  has  only  enough 
memory  to  record  two  minutes  of  noise  after  a  launch.  We  initiate  a  three-minute 
time-out  period  so  that  if  the  SSDR  fails  to  report  completion,  we  will  still  be  able  to 
go  on  to  other  tasks.  During  the  period  of  this  time-out,  we  want  to  ensure  that  a 
launch  is  recorded  in  page  0  of  the  bubble  memor>',  if  in  fact  a  launch  has  occurred.  If 
the  launchdone  flag  in  page  0  has  not  been  made  TRUE  yet,  expmtn()  calls 
baro_s>vitch().   This  funcion  will  check  the  condition  of  the  barometric  switches.   If  either 


one  has  fired,  it  will  make  the  launchdone  flag  TRUE.  The  barometric  switches  are  re- 
garded as  the  only  thoroughly  reliable  indication  of  a  launch. 

We  will  terminate  the  launch  phase  either  because  the  SSDR  reports  completion 
or  because  the  time-out  has  occurred.  We  record  whichever  of  these  is  the  case  by  call- 
ing logeventO  with  either  the  argument  DOPCOMP  or  DNOOPCOMP,  respectively. 

Unless  e.\pmnt()  detected  that  the  launch  had  been  aborted,  the  experiment  will 
ne.\l  invoke  the  function  postJaunch().  This  function  will  keep  control  until  power  is 
removed  from  the  experimental  apparatus. 

B.     SUPPORTING  SUBROUTINES  AND  FUNCTIONS 

The  major  modules  of  the  control  program  were  described  in  Section  .A..     Major 
Subroutines  and  Functions  on  page  108.    Subroutines  not  described  there  are  described 
here.   They  are  listed  alphabetically  by  the  name  of  the  source  file  in  which  they  are  de- 
fined, and  alphabetically  by  function  name  witliin  file  name. 
1.     File  bubble. c 

a.     void  bpa^esetdnt  page ) 

This  subroutine  initializes  the  parametric  registers  in  the  bubble  memor\-. 
There  are  five  of  these,  and  they  contain  information  about  the  bubble  memon's  status 
and  about  upcoming  data  transfers.  The  meaning  o[~  the  fields  within  these  registers  is 
given  in  Table  11  on  page  122.  A  complete  description  of  their  use  is  given  in  [Ref.  1: 
pp.  "^-12].  from  which  the  information  in  Table  11  on  page  122  is  taken. 


Table  11.  CONTENTS  OF  THE  PARAMETRIC  REGISTERS  IN  THE  BUBBLE 
MEMORY  CONTROLLER:  Extracted  from  [Ref.  1  :  Chapter  3.  pp. 
7-12].  


REGIS- 
TER AD- 
DRESS 

REGISTER 
NAME 

BIT 
FIELD 

CONTENTS 

OxOb 

Least  Significant 
Byte  of  the  Block 
Length  Register 

0-7 

Least  significant  eight  bits  of  the 
block  length.    The  block  length 
is  the  number  of  pages  trans- 
ferred to  or  from  the  bubble 
memory  at  one  time. 

OxOc 

Most  Significant 
Byte  of  the  Block 
Length  Register 

0-2 

Most  significant  three  bits  of  the 
block  length.    Thus  there  are  1 1 

bits  in  the  block  length,  permit- 
ting up  to  2"  =  204S  pages  to  be 
transferred  at  once. 

3 

L'nused 

4-7 

The  number  of  Formaiter  Sense 
Amplifier  channels  available. 
The  binar\"  value  0001  is  appro- 
priate here  because  we  have  only 
one  bubble  memory  attached. 
Two  channels  are  used  to  com- 
municate with  the  bubble  mem- 
ory.   With  a  single  bubble 
memory  available,  the  page  size 
is  defined  to  be  64  bytes  in 
length. 

Interrupt  enable  (normal).    We 
set  this  to  0  because  we  are  not 

0 

using  interrupts  to  communicate 
with  the  bubble  memor\-  control- 
ler. 

■ 

Interrupt  enable  (error).   We  set 
this  to  0  because  we  are  not  using 
interrupts  to  communicate  with 
the  bubble  memorv  controller. 

2 

Direct  Memor\-  Access  (DMA) 
Enable.    We  set  this  to  0  because 
we  are  not  using  DMA  with  the 
bubble  memory. 

3 

Reserved  by  Intel. 

Write  Bootlooop  Enable.    The 
bootloop  is  used  internally  to  the 
bubble  memorv.    It  need  never 

OxOd 

Enable  Register 

4 

be  rewritten  except  as  part  of  a 
diagnostic  test.    We  let  this  be  0 
since  we  don't  want  to  modify  the 
bootloop. 

5 

Enable  Read  Corrected  Data 
(RCD).    We  set  this  to  1  to  per- 
mit the  format  sense  amplifier  to 
apply  error  correction  to  errone- 
ous data.    If  the  error  is  uncor- 
rectable, then  the  erroneous  data 
will  be  transferred  to  the  host 

processor. 

Enable  Internally  Corrected  Data 
(ICD).    Setting  this  causes  the 
bubble  memorv  to  notify  the  host 

6 

processor  of  its  inability  to  cor- 
rect erroneous  data.    In  this  case, 
it  does  not  transfer  that  data. 
We  set  this  to  0  and  don't  use  the 
feature. 

7 

Enable  Parity  Interrupt.    W^e  set 
this  bit  to  0  because  we  are  not 

using  interrupts. 

OxOe 

The  Least  Signif- 
icant Byte  of  the 
Address  Register 

0-7 

The  least  significant  byte  of  the 
address.  The  address  refers  to  the 
panicular  page  within  the  bubble 
memor\'  where  data  transfers  are 
to  begin.    Since  we  are  using  a 
block  length  of  one  page,  this 
actually  addresses  the  single  page 
we  are  transferring. 

OxOf 

Most  Significant 
Byte  of  the  Ad- 
dress Register 

0-4 

Most  significant  five  bits  of  the 

address.    1  hus  there  are 

2"5  =  8192  pages  in  the  bubble 

memopv-. 

5-7 

Masnetic  Bubble  Memorv 
(MBM)  Select.   This  field  con- 
trols which  bubble  memory  is 
addressed.    Since  we  only  are  us- 
ing one  bubble  memory,  we  set 
this  to  all  zeroes. 

b.     char  issububcmd(char  command) 

This  subroutine  is  used  to  issue  a  command  to  the  bubble  memor\'  con- 
troller on  the  main  controller  circuit  board.  The  sequence  it  follows  is  given  in  detail  in 
[Ref    1:  pp. 40-45].    For  our  purposes,  the  sequence  is  as  follows: 

1.  Make  sure  the  BL  S^'  bit  is  0  before  sending  any  command  (except  ABORT).  To 
do  this,  we  read  the  status  code  in  the  BUBCTRL  port  and  check,  the  BBL  SV  bit. 

When  this  is  a  0.  we  can  proceed.  More  than  one  attempt  will  be  made  to  succeed 
in  this.  If  the  check  fails  repeatedly,  the  subroutme  displays  the  status  code  and 
returns  a  value  of  FALSE. 

2.  Issue  the  command  to  the  bubble  memor}'  controller  by  calling  the  function 
outputO. 

3.  Check  to  see  that  the  command  was  accepted.  This  is  signalled  by  the  bubble  me- 
mory controller's  setting  the  BL'SY  bit  once  again.  If  the  BL'S\'  bit  is  not  set 
within  a  reasonable  amount  of  tmie.  the  command  was  not  accepted.  In  the  case 
of  the  commands  FIFO  RESET  and  WRITE  BOOTLOOP  REGISTER,  we  can 
ignore  the  fact  that  the  BUSY  bit  never  was  set  if  we  get  an  OPER.ATION  COM- 
PLETE anyway. 

4.  Wait  for  the  OPER.ATION  COMPLETE  code  from  the  bubble  memory-  controller. 
If  this  does  not  occur  within  a  reasonable  time,  the  command  did  not  succeed. 

The  phrase  "a  reasonable  time"  in  this  subroutine  means  that  the  bubble  memon.' 
controller's  status  was  inspected  BTRIES  times  without  success.  We  have  written  the 
subroutines  such  that  they  will  regard  the  command  as  having  been  successful  if  the 
bubble  memory  controller  returns  an  OPERATION  COMPLETE  code  even  if  the 
BUSY  bit  remains  0.  ([Ref  1]  does  not  suggest  that  this  latter  indication  can  occur. 
However,  if  the  command  is  accepted  and  completed  very  quickly,  the  control  program 
might  never  observe  the  BBUSY  bit,  so  it  seems  to  be  a  good  idea  to  permit  it.) 

It  was  our  intention  that  this  subroutme  be  used  to  issue  all  commands  to 
the  bubble  memorv'.  However,  it  executed  too  slowly  to  permit  its  use  with  data  trans- 
fers.    The  subroutines  bubreadQ  and  bub>\rite(),  written  in  assembly  language,  were 


written  for  this  purpose.    In  the  case  of  other  commands.  TRUE  is  only  returned  if  the 
bubble  memor>-  returns  OPER,-\TION  COMPLETE  m  the  status  byte.    FALSE  is  re- 
turned otherwise. 
2.     File  bubnv.s 

a.  char  bubxfer(void) 

This  subroutine  is  required  during  initialization  of  the  bubble  memor\-.  It 
writes  40  OxlT  characters  to  the  bubble  memor}-.  It  returns  TRUE  if  the  transfer  worked; 
FALSE  otherwise.  The  subroutine  is  written  in  assembly  language  for  speed,  but  is 
called  in  the  same  manner  as  a  C  subroutine. 

b.  char  bubreadfchar  *buffer) 

This  subroutine  reads  data  from  the  bubble  memory  and  places  it  in  a  buffer 
whose  address  is  passed  as  a  parameter.  It  is  written  in  assembly  language  in  order  to 
execute  sufficiently  rapidly  to  preclude  overflowing  the  bufler  in  the  Bubble  Memory 
Controller  (BMC).  The  listing  of  this  subroutine  includes  many  comments  which  explain 
the  purpose  of  each  step.  The  following  is  a  list  of  the  actions  which  must  be  accom- 
plished by  this  subroutine. 

1.  Save  t!ie  contents  of  all  registers. 

2.  Issue  the  FIFO  reset  command  to  the  BMC. 

3.  Issue  the  READ  command  to  the  BMC. 

4.  Wait  for  the  BUSY  bit  to  become  a  one.    If  this  never  happens,  the  command  has 
failed. 

5.  Input  64' characters  from  the  bubble  memor>-.    The  FIFO  bit  must  be  set  to  1  be- 
fore each  character  is  read.    If  this  bit  never  becomes  a  I,  the  command  has  failed. 

6.  Restore  the  contents  of  all  registers  to  what  they  were  before  the  subroutine  began 
to  execute. 

c.  char  bubwriteCchar  *buffer) 

This  subroutine  writes  data  to  the  bubble  memory  from  a  buffer  whose  ad- 
dress is  passed  as  a  parameter.  It  is  written  in  assembly  language  in  order  to  execute 
sufficiently  rapidly  to  preclude  having  the  Bubble  Memory  Controller  (BMC)  empty  its 
internal  buffer  before  all  the  data  has  been  sent  to  it  by  the  experiment  controller.  The 
listing  of  this  subroutine  includes  many  comments  which  explain  the  purpose  of  each 
step.  The  following  is  a  list  of  the  actions  which  must  be  accomplished  by  this  subrou- 
tine. 

1.  Save  the  contents  of  all  registers. 

2.  Issue  the  FIFO  reset  command  to  the  BMC. 


3.  Issue  the  WRITE  command  to  the  BMC. 

4.  Wait  for  the  BLSY  bit  to  become  a  one.    If  this  never  happens,  the  command  has 
failed. 

5.  Output  64  characters  to  the  bubble  memory*.   The  FIFO  bit  must  be  set  to  1  before 
each  character  is  written.   If  this  bit  never  becomes  a  1,  the  command  has  failed. 

6.  Restore  the  contents  of  all  registers  to  what  they  were  before  the  subroutine  began 
to  execute. 

3.     File  clock.c 

a.  void  clockint( struct  datetime  *clock,  struct  idatetime  *iclock) 

This  subroutine  takes  a  datetime  structure  pointed  to  by  clock  and  converts 
it  to  an  idatetime  structure  pointed  to  by  iclock.  The  function  bcdjnt()  is  used  to  convert 
the  binary-  coded  decimal  (BCD)  format  used  in  the  datetime  structure  into  the  integer 
format  used  m  the  idatetime  structure. 

b.  char  clockcompare(  struct  idatetime  *clockI,  struct  idatetime  *  clock!) 

This  subroutine  compares  the  two  times  pointed  to  by  clockl  and  clock2. 
It  will  return  TRL'E  if  the  first  time  is  equal  to  or  later  than  the  second;  F.ALSE  other- 
wise. To  do  the  comparison,  each  element  of  the  time  is  compared,  from  month  down 
to  second,  in  that  order.  The  principle  difTiculty  is  in  comparing  dates  that  span  New 
^'ear's  Day.  We  want  January  1  to  be  regarded  as  coming  after  December  31.  not  be- 
fore. 

To  do  this  we  first  subtract  the  second  month  from  the  first.  The  dilTerence 
is  taken  modulo  12.  The  modulo  operation  would  not  change  any  difference  from  0 
through  11;  a  difiference  of —11  through  —1  would  be  changed  to  1  through  11  respec- 
tively. Results  in  the  range  1  through  5  indicate  that  the  first  date  is  later  than  the  sec- 
ond. 

For  example,  if  the  first  date  is  January  (month  1)  and  the  second  date  is 
December  (month  12),  the  difference  is  1  —  12  =  — 11.  When  this  is  taken  modulo  12, 
we  get  1.   Thus  January  is  1  month  after  December. 

If  the  first  date  is  June  (month  6)  and  the  second  date  is  December  (month 
12),  the  difference  is  6  —  12  =  —6.  Taken  modulo  12,  this  is  6.  Since  this  is  greater  than 
5,  we  regard  June  as  coming  before  December,  not  after. 

c.  void  clocksum(  struct  idatetime  *  result,  struct  idatetime  *  clockl,  struct 
idatetime  *clock2) 

This  subroutine  adds  together  the  date  and  time  pointed  to  by  the  idatetime 
structure  clockl  to  the  number  of  months,  days,  etc.  in  the  idatetime  structure  pointed 


to  by  clocL2.  yielding  a  new  idatetime  structure  pointed  to  by  result.  This  is  useful  when 
from  a  given  date  and  time  one  wishes  to  calculate  a  later  date  and  time.  The  usual  use 
of  this  subroutine  is.  given  the  current  date  and  time,  to  calculate  the  date  and  time  after 
some  given  delay  has  elapsed. 25 

It  starts  by  adding  the  seconds  together,  and  works  from  there  up  to  the 
months.  After  each  addition,  checks  are  made  to  ensure  that  the  result  is  valid.  If  not 
{e.g.,  63  minutes  is  not  valid),  the  result  is  corrected  and  any  excess  is  carried  over  to  the 
next  highest  unit  of  time. 

The  fact  that  diiTerent  months  have  different  lengths  is  a  bit  of  a  nuisance 
which  is  overcome  by  considering  the  three  possible  cases:  a  month  can  have  31  days, 
30  days  or  2S  days.  Leap  years  are  ignored,  since  the  real-time  clock  does  not  store  the 
current  year,  and  so  is  unaware  of  leap  years. 

d.  void  show _\vaketime( struct  idatetime  *Kaketime) 

This  function  displays  the  date  and  time  stored  m  the  idatetime  structure 
pointed  to  by  "aketime  on  the  terminal. 

e.  void  dump_iclock( struct  idatetime  *clock) 

This  subroutine  displays  the  date  and  time  (when  stored  in  integer  format) 
on  the  terminal. 

f.  void  get  _time(  struct  idatetime  *  clock) 

This  subroutine  asks  the  user  for  the  date  and  time.  Each  response  is 
checked  for  correctness  to  preclude  invalid  dates  and  times  being  entered.  The  function 
getintO  is  used  to  get  the  responses  from  the  keyboard.  The  responses  are  converted  to 
binan.-coded  decimal  (BCD)  format  and  stored  in  the  structure  whose  address  is  passed 
as  a  parameter  to  the  function. 

g.  void  show _}vaketime( struct  idatetime  *waketime) 

This  subroutine  displays  on  the  terminal  the  date  and  time  when  a  time-out 
will  have  been  completed.  The  date  and  time  are  provided  in  the  structure  whose  address 
is  passed  as  a  parameter. 

h.     char  timeoutdnt  delaytime,  int  measure) 

This  subroutine  has  two  purposes: 

1.  It  initiates  a  time-out  sequence. 

2.  It  checks  to  see  whether  a  time-out  sequence  has  been  completed  yet.    This  is  the 
case  when  the  wake-up  time  calculated  previously  has  been  reached. 


25  While  It  could  be  used  to  add  two  dates  together,  this  would  not  be  particularly  meaningful. 


The  subroutine  calls  the  function  allow_ctrlJnterrupts()  to  permit  its  being 
interrupted  during  ground  testing  by  the  depression  of  a  key  on  the  terminal.  It  then 
calls  clockreadO  to  get  the  current  date  and  time.  This  is  converted  to  integer  format 
by  a  call  to  cIockint().  If  the  parameter  delajlime  is  the  constant  NULL,  then  the 
function's  purpose  is  to  see  whether  a  time-out  set  previously  has  expired.  The  function 
clockcompareO  is  invoked  to  compare  the  stored  date  and  time  with  the  current  date  and 
time.    Its  result  is  returned  as  the  result  of  timeout(). 

If  the  parameter  delajlime  is  not  the  constant  NULL,  then  the  function's 
purpose  is  to  initiate  a  time-out  sequence.  The  structure  uaittime  is  initialized  to  zero. 
One  of  its  elements  is  then  modified  to  contain  the  number  of  delay  units  passed  as  the 
parameter  delaytime.  Which  element  is  modified  is  determined  by  the  parameter 
measure,  which  can  take  on  the  values  MONTH,  DATE.  HOURS.  MINUTES,  or 
SECONDS.  The  subroutine  clocksum()  is  called  to  add  together  the  current  time  and 
the  amount  of  time  to  wait.  The  result  is  displayed  by  calling  the  function 
sho\v_\\aketime().  The  wake-up  time  is  stored  in  a  global  structure,  \\aketime.  so  its 
contents  will  be  undisturbed  the  next  time  this  function  is  called. 
4.     File  convert.c 

a.  char  atoh(char  *ascii) 

This  function  converts  the  two-character  hexadecimal  string  pointed  to  by 
ascii  and  converts  it  to  a  single  character. 26  If  the  characters  in  ascii  are  in  the  range  '0' 
through  '9'  or  'a'  through  T.  then  the>  will  be  properly  interpreted  as  hexadecimal  digits. 
Capital  letters  ('A'  through  'F')  and  any  other  characters  are  treated  as  zeros.  For  ex- 
ample, the  character  string  "63""  would  be  converted  to  the  single  character  'c'.  since  the 
hexadecimal  representation  of  this  ASCII  character  is  0x63. 

b.  unsigned  int  atohexint(char  asciif  J) 

This  subroutine  converts  a  four-byte  ASCII  string  of  characters  which  rep- 
resent a  valid  hexadecimal  word  into  a  single  unsigned  integer.  No  checks  are  made  to 
see  that  the  character  string  is  valid,  but  invalid  characters  are  sufficient  to  cause  the 
subroutine  to  stop  processing  the  character  string.  If  no  valid  string  of  hexadecimal 
characters  is  found,  the  value  0  is  returned  by  this  subroutine. 

c.  int  atoi(char  *s) 

This  function  converts  a  four-character  string  to  an  integer.  The  string  may 
optionally  include  a  sign  (-(-or-)  in  the  first  position.     Successive  characters  will  be 


26  No  check  is  made  to  ensure  that  ascii  is  only  two  characters  in  length. 
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converted  to  numeric  values  if  they  are  in  the  range  '0'  through  '9'.  Conversion  ceases 
as  soon  as  a  character  fails  to  fall  within  this  range.  No  checking  is  done  to  ensure  that 
the  number  of  digits  provided  can  fit  within  the  number  of  bytes  reserved  for  integers. 
This  subroutine  is  from  Bilofsky  [Ref  18]. 

d.  char  *  bed _asc(  char  bed) 

This  function  converts  a  binary  coded  decimal  (BCD)  character  into  an 
ASCII  string.  For  example,  the  single  byte  0x63  is  converted  to  a  two-character  string 
"63".  The  BCD  character  is  first  converted  to  an  integer.  It  is  assumed  that  an  integer 
occupies  two  bytes.  If  the  leading  nibble  of  the  character  is  a  0,  it  will  be  converted  to 
a  space  ('  ').  No  check  is  made  to  see  if  the  BCD  character  is  valid.  The  function  returns 
a  pointer  to  the  ASCII  string  representation. 

Since  it  always  uses  the  same  storage  location  to  hold  the  converted  result, 
the  string  should  be  copied  to  another  variable  before  bcd_ascii()  is  called  again,  for  the 
old  contents  will  be  destroyed. 

e.  int  bcdjntfchar  bed) 

This  function  converts  a  binary  coded  decimal  (BCD)  character  into  an  in- 
teger. No  checking  is  done  to  ensure  the  BCD  character  is  valid.  The  integer  result  is 
returned. 

/.     char  *ctoh(char  byte) 

This  function  converts  a  character  byte  into  a  hexadecimal  string  represen- 
tation.   It  returns  a  pointer  to  the  string.    Since  it  always  uses  the  same  storage  location 
to  hold  the  converted  result,  the  string  should  be  copied  to  another  variable  before  ctoh() 
is  called  again,  for  the  old  contents  will  be  destroyed. 
g.     char  int_bed(int  decimal) 

This  function  converts  an  integer  into  BCD  format.    It  will  handle  positive 
integers  in  the  range  0  through  99.  No  checking  is  done  to  ensure  the  integer  falls  within 
this  range.   The  function  returns  the  BCD  result  as  a  single  character. 
h.     char  *itoa(int  n,  charf  J) 

This  function  converts  an  integer  n  into  an  ASCII  representation.  It  con- 
verts the  integer  into  digits  by  taking  it  modulo  10  and  storing  the  digits  in  character 
form  in  reverse  order.  Upon  completion,  it  reverses  the  string  in  place.  The  result  is 
stored  in  the  location  pointed  to  by  the  parameter  s.  No  check  is  made  to  ensure  this 
location  has  enough  storage.  This  is  the  user's  responsibility.  However,  in  a  machine 
with  two-byte  integers,  the  largest  possible  integer  will  contain  five  digits.     The  user 


should  allow  two  extra  locations  for  the  sign  and  the  terminating  NULL  character,  or 
seven  characters  in  all.    This  subroutine  is  from  Bilofsky  [Ref.  18]. 
/.     char  tolower(mt  c) 

This  function  converts  upper  case  alphabetic  characters  into  lower  case 
ones.  This  subroutine  is  from  Bilofsky  (Ref.  18].  Its  use  here  is  a  consequence  of  our 
having  used  this  C  compiler  during  the  early  work  on  this  project.  This  function  is 
provided  in  the  librarv'  supplied  with  the  L'niware  C  Compiler;  with  the  Toolworks  C 
Compiler,  its  source  code  had  to  be  included  with  our  source  code.  It  could  have  been 
removed  when  we  switched  over  to  using  the  Uniware  C  Compiler,  but  it  never  was. 
There  exist  other  vestiges  of  our  early  use  of  the  Toolworks  C  Compiler  that  have  never 
been  eradicated. 

j.     char  *uitoh( unsigned  int  word) 

This  subroutine  converts  an  unsigned  integer  to  hexadecimal  ASCII  string 
format.  For  example,  the  unsigned  integer  '28'  is  converted  to  the  character  string 
"IC"  since  that  is  its  ASCII  representation. 

5.  File  delay.s 

a.     void  delay  (int  n) 

This  function  provides  a  tiniing  delay  of  n  x  10  ms  .  It  is  written  in  Z-80 
assembly  language.  It  will  only  work  correctly  if  the  system  clock  has  frequency  f  =  2.5 
MHz.  It  is  adapted  from  a  program  written  by  Mr.  David  Rigmaiden  of  the  Naval 
Postgraduate  School. 

6.  File  expmnt.c 

a.  char  ad_read(char  port) 

This  subroutine  will  obtain  one  character  from  that  channel  of  the  Ana- 
log-to-digital {A  D)  Converter  whose  address  is  pass  as  the  parameter  port.  It  functions 
by  writing  anything  at  all  to  that  port  address  (we  chose  arbitrarily  to  send  a  0),  then 
by  waiting  for  one  10  ms  period  during  which  the  AD  converter  responds,  and  then  fi- 
nally by  reading  a  character  from  the  same  port.  This  is  the  character  returned  by  the 
subroutine. 

b.  int  adtoint(char  addata,  unsigned  long  multiplier) 

The  purpose  of  this  subroutine  is  to  convert  a  character  input  from  the 
Analog-to-digital  (A/D)  Converter  into  an  integer  which  represents  the  measured  quan- 
tity in  more  meaningful  units  than  an  arbitrar>-  number  in  the  range  [0,255],  which  is  all 
that  the  A,  D  converter  can  provide.  It  would  be  natural  to  perform  the  arithmetic 
scaling  of  the  input  eight-bit  number  addata  to  the  corresponding  output  value  by  per- 


forming  ordinary  floating-point  multiplication  and  division.  This  has  one  drawback  in 
a  microprocessor  application:  the  executable  code  to  support  floating  point  operations 
takes  up  rather  a  large  amount  of  memory.  In  tests  we  performed  using  the  floating 
point  arithmetic  operators  provided  with  the  Uniware  C  Compiler,  the  subroutines  re- 
quired two  extra  EPROMS  of  8  KBytes  apiece.  We  had  the  room  in  our  controller  to 
accept  this,  but  chose  not  to  do  so  since  our  need  for  floating  point  arithmetic  was  lim- 
ited to  this  one  function.  To  program  two  complete  EPROMS  every  time  a  new  version 
of  the  program  was  compiled  solely  to  provide  this  one  use  of  floating  point  of  arith- 
metic was  not  warranted,  in  our  judgement. 

The  alternative  was  to  perform  the  scaling  operation  with  fixed  point  arith- 
metic. The  C  programming  language  supports  integer  operations,  but  fixed  point  oper- 
ations with  a  movable  decimal  point  are  not  supported.  This  subroutine  uses  an  implied 
decimal  point.  As  far  as  the  subroutine  is  concerned,  the  operands  are  integers,  plain 
and  simple.  By  using  unsigned  long  integers,  we  have  32  bits  o{  accuracy,  permitting 
numbers  in  the  range  [0.4.2949672*^6  x  10'].  For  our  purposes,  we  have  have  used  a  di- 
visor of  10".   This  has  the  effect  of  reducing  the  range  of  useful  numbers  to  [0.4294]  . 

The  purpose  of  these  manipulations  is  to  permit  all  the  accuracy  promised 
by  the  provision  of  eight  bits  from  the  A  D  converter  while  avoiding  floating  point 
arithmetic.  The  details  of  the  operation  are  included  as  comments  in  the  program  Usting, 
so  will  not  be  repeated  here. 

c.     void  alter _pagi'0( struct  pageOiiata  *  pagezero) 

This  subroutine  permits  the  user  to  alter  the  flags  stored  in  page  0  of  the 
bubble  memor>'.  Since  these  flags  describe  the  current  status  of  the  experiment,  and  also 
indicate  which  area  of  the  bubble  memory  is  available  for  use.  their  alteration  amounts 
to  initializing  the  status  of  the  experiment  to  a  known  value.  The  use  of  this  subroutine 
is  described  in  Chapter  V.  HOW  TO  GET  THE  EXPERIMENT  READY  FOR  A 
LAUNCH  on  page  63.  It  displays  a  menu  using  the  same  method  used  in  so  many  other 
functions  in  the  control  program.  This  method  was  already  presented  in  the  description 
of  the  function  main().  A  Mhile  loop  presents  the  menu  repeatedly  until  choice  Z  is 
made.  The  menu  shows  the  current  values  of  all  the  information  stored  in  page  0  of  the 
bubble  memorv-.  In  most  cases  it  also  shows  the  other  possible  value  of  each  flag.  The 
sole  exceptions  are  the  value  of  the  next  available  page,  which  can  fall  in  the  range 
[1,8191],  and  the  flag  RECORD_startJime,  which  is  a  date  and  time. 

If  any  of  the  values  is  changed,  page  0  is  rewritten. 
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d.  char  bad Jdea_tojecord( char  show) 

In  the  abridged  experiment,  the  only  phase  of  the  experiment  is  record.  It 
would  be  unfortunate  if  the  Solid  State  Data  Recorder  were  restarted  in  record  mode 
after  the  launch  had  already  occurred,  for  this  would  erase  the  recording  of  the  launch 
and  replace  it  with  the  silence  that  fills  the  cargo  bay  in  space,  or  possibly  all  the  sounds 
of  the  launch  except  the  moment  of  ignition  of  the  solid  rocket  motors.  How  could  this 
happen?  A  power  fault,  for  whatever  reason,  would  cause  the  controller  to  start  at  the 
beginning  upon  the  restoration  of  power.  There  is  no  obvious  way  for  the  controller  to 
be  sure  that  it  is  still  on  the  ground,  which  certainly  is  the  only  time  when  it  is  really  a 
good  idea  to  initiate  the  record  phdiSt.  Of  course,  it  is  easy  to  determine  whether  it  is  in 
space  or  not  simply  by  checking  the  status  of  the  barometric  pressure  switches.  Our 
solution  is  simply  to  prohibit  the  initiation  of /■t'co/c/ mode  more  than  once  in  12  hours. 
If  a  mission  is  scrubbed,  it  will  be  at  least  24  hours  before  it  is  rescheduled.  The  12  hour 
delay  will  have  elapsed  by  this  time,  and  the  abridged  experiment  could  then  be  per- 
formed as  planned. 

The  long  and  the  short  of  these  considerations  is  that  this  function  com- 
pares the  current  time  to  the  time  when  record  was  last  initiated.  This  time  is  stored  in 
page  0  of  the  bubble  memor>'.  If  insulTicient  time  has  elapsed,  the  function  returns  the 
value  TRUE,  meaning  that  it  is  a  bad  idea  to  record.  If  12  hours  has  elapsed,  it  returns 
the  value  FALSE,  meaning  it  is  not  a  bad  idea  to  record;  record  mode  can  be  initiated, 
in  this  case. 

e.  void  display _pageO( struct  pageOdata  *  pagezero) 

This  subroutine  displays  the  contents  of  page  0  of  the  bubble  memon.'  on 
the  terminal. 

/.     void  do_sweep(  void) 

This  function  performs  the  sweep  phase  of  the  unabridged  experiment.  It 
turns  on  (and  logs  the  fact  that  it  has  done  so)  the  Analog-to-digital  (AD)  Converter 
and  the  Solid  State  Data  Recorder  (SSDR).  It  then  commands  the  SSDR  to  enter  sweep 
mode.  After  a  10  second  time-out,  it  appUes  power  to  the  Voltage  Controlled  Oscillator 
(VCO)  which  is  responsible  for  filling  the  Space  Shuttle  cargo  bay  with  sounds  of  known 
frequency. 

Next  it  initiates  a  13  minute  time-out.  The  SSDR  should  signal  completion 
of  the  sweep  phase  before  this  much  time  has  elapsed.  If  this  does  not  happen,  the 
time-out  allows  the  control  program  to  stop  waiting  for  it  to  do  so.    Upon  completion 


of  the  sweep  phase,  the  do_s\\eep()  phase  removes  power  from  the  VCO,  SSDR.  and  A  D 
converters. 

g.     char  initialize  (void) 

This  subroutine  extracts  the  status  information  from  page  0  of  the  bubble 
memorv'  when  the  expmnt()  program  begins  to  execute.  It  will  remove  power  from  the 
Voltage  Controlled  Oscillator  (VCO),  which  performs  the  sweep  phase,  and  from  the 
heater  subsystem,  if  either  of  these  is  on.  It  will  not  remove  power  from  the  other  sub- 
systems, which  also  might  be  on  when  power  is  first  applied.  How  can  this  be,  and  why 
does  it  not  remove  power  from  them?  One  way  in  which  power  might  be  applied  is  after 
a  brief  power  fault.  If  the  fault  affected  the  controller  but  not.  say,  the  Sohd  State  Data 
Recorder  (SSDR),  and  '\^  sweep  mode  had  been  initiated  prior  to  the  loss  of  power,  re- 
moving power  from  the  SSDR  would  have  the  effect  of  terminating  sv.-eep  mode  and  this 
would  raise  the  possibility  that  an  othenvise  successful  recording  o'i  the  ignition  of  the 
sohd  rocket  motors  would  be  foiled.  The  SSDR  and  other  subsystems,  therefore,  should 
not  be  interfered  with  at  this  point. 

h.     char  listen(void) 

This  subroutine  applies  power  to  the  matched  filter  circuit  board.  It  then 
calls  wejaunched().  This  function  returns  DLAUNCH  if  a  launch  has  occurred,  and  this 
value  is  returned  by  listen(),  too.  if  a  launch  has  not  yet  occurred,  listen()  checks  to  see 
if  the  matched  filter  has  detected  the  starting  of  the  Auxiliary  Power  Units  (APUs).  If 
so.  the  function  returns  the  value  DAPLON.  If  neither  condition  has  occurred,  the 
function  calls  the  subroutine  look_ahead_discard().  giving  the  user  (if  any)  to  get  out  of 
the  listenO  function  by  depressing  any  key  on  the  terminal.  Barring  one  of  these  three 
conditions,  the  function  will  continue  making  these  same  checks  indefinitely. 

/.     char  logevent(char  event) 

This  subroutine  makes  coded  entries  in  the  bubble  memory  of  all  events 
which  take  place.  While  it  is  doing  this,  it  takes  readings  from  each  of  the  channels  of 
the  Analog-to-digiial  (A  D)  Converter  and  stores  the  results  in  the  same  page  of  the 
bubble  memory-  in  which  the  event  code  is  stored.  If  the  bubble  memor\-  is  already  full, 
which  would  occur  after  2x8191  =  16,382  events,  the  subroutine  refuses  to  store  any 
more  events.  This  will  preclude  the  destruction  of  the  records  of  earlier  events.  How- 
ever, we  do  not  expect  this  many  events  ever  to  occur  on  a  single  mission  of  the  Space 
Shuttle.  The  interval  between  successive  events  after  the  first  two  minutes  of  flight  is  five 
minutes;  at  this  rate,  it  would  take  nearly  57  days  to  fill  up  the  memory. 


There  are  two  possibilities  when  the  function  prepares  to  write  a  page  of 
information  to  the  bubble  memor>'.  Either  this  is  a  brand  new  page,  or  it  is  the  second 
half  on  an  existing  page  of  stored  data.  In  the  former  case,  the  second  half  of  the  page 
is  filled  with  NULL  characters.  This  efTectively  erases  any  data  previously  stored  in  this 
upper  half-page.  The  subroutine  next  reads  the  current  date  and  time  and  stores  this  in 
the  structure  where  all  the  information  is  assembled  prior  to  being  transferred  to  the 
bubble  memory.  The  event  code  is  passed  to  the  function  logevent()  as  parameter  event 
to  be  stored  in  the  bubble  memor>'.  Each  channel  of  the  AD  converter  is  sampled  and 
the  results  also  are  stored  in  the  bubble  memory.  If  the  event  code  is  CSSWEEP,  then 
the  command  to  initiate  sweep  mode  has  just  been  issued,  and  the  flag  s>veepstarted  in 
page  0  needs  to  be  set  to  TRUE.  If  the  event  code  is  DPRESSURE,  then  the  flag 
launchdone  in  page  0  needs  to  be  set  to  TRUE.  Then  the  new  record  of  information  can 
be  written  to  the  next  available  half  of  the  next  available  full  page  of  the  bubble  niemorv-. 
The  page  number  and  half  page  number  are  extracted  from  page  0  of  the  bubble  mem- 
ory. Page  0  needs  to  be  updated,  and  this  is  done  also. 
j.     void  log_jnenu(  void) 

This  subroutine  provides  the  user  with  a  menu  for  changing  the  contents 
of  page  0  of  the  bubble  memorv'.  Recall  that  this  Information  describes  the  current  sta- 
tus of  the  experiment.  It  is  important  that  this  information  be  initialized  correctly  prior 
to  the  launch  of  the  Space  Shuttle.  How  to  do  this  is  described  in  Chapter  V.  HOW 
TO  GET  THE  EXPERIMENT  READY  FOR  A  LAUNCH  on  page  63. 

The  details  of  how  the  menu  is  generated  are  the  same  as  explained  in  the 
description  of  the  function  nienuQ  and  will  not  be  repeated  here. 
k.     void  monitor _heaters( void) 

This  subroutine  has  the  job  of  maintaining  the  temperature  of  the  bubble 
memor\-  at  a  sufficiently  high  level  that  it  can  be  operated  safely.  If  it  finds  that  the 
current  temperature  is  lower  than  the  minimum  desirable  temperature  (12°C)  it  will  turn 
the  heaters  on.  If  it  finds  that  the  temperature  is  above  the  maximum  desirable  tem- 
perature {14°C).  it  will  turn  the  heaters  off.  This  is  not  the  temperature  above  which  the 
bubble  memories  will  lose  their  memor\'.  Rather  it  is  a  temperature  chosen  to  be  shghtly 
higher  than  the  minimum  desirable  temperature.  If  the  temperature  can  attain  this  level, 
the  heaters  will  be  shut  off  for  a  while  to  save  power.  If  the  temperature  falls  to  the 
minimum  desirable  level,  this  still  is  2°C  above  the  minimum  operating  temperature,  al- 
lowing a  reasonable  margin  for  safe  operation.  The  2°C  spread  is  wide  enough  to  pre- 
clude excessively  frequent  operation  of  the  relay  switches,  too. 
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/.     void  pos  tjaunch  (  void) 

This  subroutine  performs  the  caretaking  functions  that  follow  the  successful 
launch  of  the  Space  Shuttle.  Its  first  action  is  to  remove  power  from  all  subsystems. 
It  then  mitiates  a  five  minute  time-out.  During  this  wait,  it  calls  monitor_heaters()  re- 
peatedly to  give  them  an  operation  to  operate  the  heater  subsystem.  It  also  checks  the 
barometric  pressure  switches  if  they  have  not  yet  reported  a  completed  launch.  During 
ground  testing  it  is  useful  to  have  a  way  of  interrupting  this  phase  of  the  mission. 
Calling  look_ahead_discard()  lets  the  user  do  so  by  pressing  any  key  on  the  terminal. 
At  the  completion  of  the  five  minute  delay,  logeventQ  is  called  to  record  a  "read  AD" 
event.  The  function  logevent()  takes  care  of  reading  all  the  Analog-to-digital  Converter 
(A  D)  channels  whenver  it  is  called.  Finally,  a  call  to  voltagesJo>v()  is  made  to  ensure 
that  if  the  voltages  on  the  lOV  power  busses  falls  to  too  low  a  level,  the  experiment  will 
be  terminated.  This  will  preclude  an  attempt  to  operate  the  bubble  memories  with  in- 
sufficient current,  which  could  cause  them  to  lose  their  contents. 
m.     void  record(  void) 

This  subroutine  performs  the  record  phd^t  of  the  abridged  experiment.  The 
first  action  taken  by  this  subroutine  is  to  read  the  current  date  and  time  and  to  place  this 
information  in  the  structure  of  data  to  be  stored  in  page  0  of  the  bubble  memory.  A  call 
to  logevent()  immediately  after  this  has  the  effect  of  ensuring  that  this  date  and  time  are 
transferred  to  page  0  right  away,  along  with  taking  current  readings  of  all  the  channels 
of  the  Analog-to-digital  (AD)  Converter. 

The  recordO  subroutine  then  applies  po\\er  to  the  A  D  converters  and  the 
Solid  State  Data  Recorder  (SSDR).  commands  the  SSDR  to  enter  record  mode,  and  in- 
itiates a  20  minute  time-out.  The  SSDR  should  report  completion  of  record  mode  prior 
to  the  expiration  of  this  delay,  but  even  if  it  fails  to  do  so,  the  subroutine  will  be  able  to 
terminate  the  record  phase  of  the  experiment.  While  waiting  for  the  20  minutes  to 
elapse,  the  subroutine  calls  baro_switch()  if  that  function  has  not  previously  reported  a 
successful  launch.  Upon  the  completion  of  the  record  phase,  the  subroutine  removes 
power  from  both  the  SSDR  and  the  A  D  converter. 
n.     void  short _experiment(  void) 

This  subroutine  performs  the  abridged  experiment.  It  first  checks  to  see 
whether  a  launch  had  occurred  previously.  This  could  be  the  case  if  a  power  fault  had 
caused  the  controller  to  start  executing  its  program  from  the  beginning.  If  a  launch  has 
been  recorded  already,  the  subroutine  refuses  to  put  the  Solid  State  Data  Recorder 


(SSDR)  into  record  mode.    This  will  prevent  the  successful  recording  of  a  launch  to  be 
wiped  out. 

If  a  launch  has  not  occurred  previously,  then  the  subroutine  will  wait  until 
it  is  alright  to  initiate  record  mode.  This  is  indicated  by  the  subroutine 
badJdea_to_record()  returning  the  value  FALSE,  meaning  it  is  not  a  bad  idea  to  start 
record  phase.  Next  the  subroutine  will  call  listen()  to  listen  for  the  starting  of  the  Aux- 
iliary Power  Units  (APUs).  The  listen()  subroutine  will  keep  control  until  either  the 
APUs  start,  or  until  some  indication  of  a  launch  is  detected.  At  this  point,  the  record 
phase  is  initiated. 

It  is  conceivable  that  at  the  end  of  the  record  phase,  we  w^ould  discover  that 
we  had  jumped  the  gun  and  that  the  Space  Shuttle  was  still  on  the  ground.  To  see 
whether  or  not  this  is  the  case,  the  subroutine  calls  baro_s>vitch().  if  that  subroutine  had 
not  previously  reported  that  launch  had  defmitely  been  completed.  If  no  launch  has 
occurred,  we  are  in  a  bit  of  a  quandar}'.  Is  launch  imminent?  How  long  will  it  be  before 
it  occurs?  It  would  be  nice  simply  to  re-initiate  record  mode,  but  this  consumes  consid- 
erable power.  What  is  potentially  worse,  the  power  fault  might  occur  at  the  moment 
of  launch.  It  will  still  be  several  moments  before  the  barometric  switches  indicate  that 
a  launch  has  occurred.  Smce  we  cannot  ascertain  whether  the  launch  has  occurred  or 
not,  it  is  best  to  assume  that  it  has  and  not  to  re-initiate  record  phase,  which  would  erase 
the  recording  of  the  launch.  So  we  have  adopted  the  solution  of  waiting  until  at  least 
12  hours  more  have  elapsed  before  entering  the  record  phase  again. 

At   the   successul  completion  both   of  record  phase  and  a  launch,  the 
short_e.\periment()  subroutine  calls  posMauncliQ  to  perform  all  the  caretaking  functions 
required  during  the  Space  Shuttle's  mission. 
0.     void  show jevent( char  event) 

This  function  is  used  to  display  event  codes  stored  in  the  bubble  memon,'  log 
in  a  readable  form  on  the  display  terminal.    It  does  this  by  displaying  the  appropriate 
character  string  from  an  array  of  strings  which  describe  the  various  codes. 
p.     void  shut _down( void) 

This  function  removes  power  from  any  subsystem  which  currently  is  re- 
ceiving power.   It  calls  logevent()  to  record  any  actions  it  takes. 
q.     char  ssdrmode(char  mode) 

This  subroutine  issues  commands  to  the  Solid  State  Data  Recorder  (SSDR). 
If  the  command  is  unsuccessful  the  first  time,  it  will  make  several  more  tries  before  giv- 
ing up.    Once  the  command  has  been  issued,  the  subroutine  waits  for  20  ms  and  then  it 


checks  the  status  code  returned  by  the  function  ssdr_status().  The  desired  response  from 
the  SSDR  is  that  the  commanded  operation  has  been  completed  successfully,  which  is 
mdicated  by  the  return  of  the  constant  XORMOP.    The  subroutme  ssdrmode()  returns 
TRUE  if  this  occurs;  FALSE  otherwise. 
r.     char  ssdr_status(void) 

This  subroutine  reads  the  status  code  from  the  Solid  State  Data  Recorder 
(SSDR)  and  returns  it  to  the  calling  function. 
s.     char  v olt age s_Ioh( void) 

This  function  checks  the  channel  of  the  Analog-to-digital  (AD)  Converter 
which  allow  the  measurement  of  voltage  on  the  lOV  bus.  The  value  read  is  converted 
to  voltage  by  ihe  function  adtoint().  If  that  voltage  falls  below  the  minimum  voltage 
desirable  on  the  lOV  bus,  then  the  function  returns  the  value  TRUE,  meaning  that  the 
voltages  are  too  low,  and  that  the  experiment  should  halt.  Othenvise  it  returns  the  value 
FALSE. 

t.     char  we Jaunchedf  void ) 

This  subroutme  first  calls  the  function  baro_snitch()  to  see  whether  the  ba- 
rometric pressure  switches  have  detected  an  ascent  of  the  Space  Shuttle.    If  this  has  oc- 
curred,  or  if  the   Vibration-activated   Launch   Detector  has  detected  a  launch,   this 
function  returns  the  value  DL.AUNCH.    Otherwise  it  returns  the  value  FALSE. 
7.     File  fputc.c 

a.     int  fputcdnt  chr,  void  *  device) 

The  UNIWARE  compiler  provides  the  standard  C  output  subroutine 
printfO  to  provide  output  to  the  standard  output  device.  Howe\er.  this  subroutine  re- 
quires the  user  to  provide  a  subroutine  fputc()  to  handle  the  output  of  a  single  character 
to  any  arbitran."  device.  We  only  support  output  by  fputc()  to  the  RS-232C  terminal,  so 
this  subroutine  is  specific  to  that  device. 

This  function  calls  the  subroutine  allo»_ctrl_interrupts()  to  permit  the  user 
to  interrupt  operation  of  the  control  program.  The  subroutine  will  not  output  a  char- 
acter if,  upon  checking,  it  finds  there  is  no  tenninal  attached  to  the  serial  interface  port. 
Thus,  when  the  experiment  is  operating,  calls  to  printf()  are  of  no  effect  unless  there  is 
a  terminal  connected. 

The  subroutine  returns  -1  if  there  is  no  terminal  connected.  This  is  the 
code  specified  by  UNIWARE  if  fputc()  is  unable  to  do  the  output  operation.  If  there 
/5  a  terminal  attached.  fputc()  repeatedly  polls  the  serial  interface,  waiting  for  it  to  be 


ready  to  accept  output  data.    It  then  outputs  the  character,  and  returns  that  character, 
again  as  specified  by  UNIWARE.  [Ref.  17:  Compiler  Section,  pp.   45  and  52J 

8.  File  global.c 

This  file  contains  the  declarations  of  variables  used  throughout  the  control 
program.  The  author's  predilection  is  to  avoid  the  use  of  global  variables.  However,  it 
can  sometimes  become  so  awkward  to  observe  this  preference  as  to  make  it  silly.  It  is 
desirable  to  hold  the  use  of  global  variables  to  a  minimum,  however. 

9.  File  inout.c 

a.  void  allow _ctrl_interrupts( void) 

This  subroutine  makes  it  possible  for  the  user  to  interrupt  the  execution  of 
the  control  program.  Whenever  it  gets  control,  it  calls  the  function  look_ahead()  to  see 
if  any  key  of  the  terminal  has  been  depressed  by  the  user.  If  not,  then  the  function  re- 
turns without  further  ado.  If  a  key  has  been  depressed,  however,  it  may  have  been  one 
of  the  two  control  keys  CTRL  Y  or  CTRL  S.  If  so.  the  function  termini)  is  called  to 
remove  the  character  from  the  input  buffer,  and  to  respond  appropriately  to  the  input 
control  character. 

b.  void  dump  (unsigned  int  address,  unsigned  int  length) 

This  subroutine  displays  the  contents  of  a  section  of  memon."  on  the  display 
terminal.  The  variable  address  designates  the  address  of  the  first  character  of  data  to 
be  displayed.  The  variable  length  specifies  how  many  characters  to  display.  The  display 
shows  a  hexadecimal  representation  of  every  character  in  the  chosen  section  of  memory. 
and  if  that  character  has  a  printable  form,  that  form  also  is  displayed.  This  function  is 
of  value  only  for  debugging  the  control  program. 

c.  char  gethex(void) 

This  subroutine  obtains  a  hexadecimal  string  from  the  terminal.  Up  to 
HSTRLEN  characters  will  be  accepted.  Processing  will  cease  as  soon  as  a  character  not 
in  the  ranges  '0'  through  '9',  *a'  through  T,  or  'A'  through  'F'  is  entered.  The  input 
string  will  be  converted  to  a  single  character  by  calling  atohQ,  and  this  character  will  be 
returned.  For  example,  the  string  "6a"  would  be  converted  to  the  ASCII  character  'j', 
whose  hexadecimal  representation  is  0x6a.  This  subroutine  is  useful  for  getting  one-byte 
system  port  addresses  from  the  user  if  he  is  more  likely  to  know  them  in  hexadecimal 
than  in  decimal. 

d.  unsigned  int  gethexint(void) 

This  subroutine  is  ver\'  similar  to  gethexQ,  except  that  it  accepts  two  hexa- 
decimal bytes,  not  just  one. 


e.     int  getint(void) 

This   subroutine   obtains  a   decimal   string   from  the   keyboard.      Up   to 
STRLEN  -  1  digits  can  be  entered.    Processing  will  cease  as  soon  as  a  character  not  in 
the  range  '0'  through  '9"  is  entered.    The  input  string  will  be  converted  to  an  integer  by 
calling  atoi(),  and  this  value  will  be  returned. 
/.     int  getpageno(void) 

This  subroutine  obtains  a  page  number  in  bubble  memory  from  the  user. 
Valid  responses  are  in  the  range  0  through  MAXPAGE.  It  uses  the  subroutine  getintQ 
to  obtain  the  response. 

g.     char  look _ahead( char  *character) 

This  function  checks  to  see  if  a  key  has  been  pressed  on  the  display  terminal. 
Of  course,  if  there  is  no  terminal  attached,  there  is  no  point  in  even  looking,  so  the 
function  returns  instantly  in  this  case  with  a  value  of  FALSE.  The  variable 
console_data_available  is  owq  of  two  variables  known  to  all  functions  in  the  file  inout.c. 
It  will  have  the  value  TRUE  if  the  function  look_aliead()  or  the  function  termin()  dis- 
covered previously  that  there  was  a  character  available  to  be  read.  The  look_ahead() 
returns  this  character  to  the  calling  function  for  it  to  inspect,  but  it  does  not  remove  the 
character  from  the  buHer.  Further  calls  to  look_ahead()  or  to  terming  would  obtain  the 
same  character. 

If  there  is  no  character  already  in  the  buffer  (that  is,  if 
console_data_available  is  FALSE.)  then  look_ahead()  checks  the  RS232C  interface  to  see 
if  a  key  has  been  pressed.  If  so,  the  character  is  read  and  placed  in  the  variable 
console_buffer  for  future  use  by  look_ahead()  and  terniin().  It  also  is  returned  to  the 
calling  function,  and  the  value  of  console_data_available  is  set  to  TRUE  since  a  character 
now  is  in  the  console  buffer. 

h.     char  termin(void) 

The  primary  purpose  of  this  subroutine  is  to  read  a  character  from  the  ter- 
minal whenever  the  latter  has  one  available.  This  condition  is  known  to  be  true  when- 
ever bit  PRTRDY  of  port  PRTCTRL  is  a  1.  The  input  character  is  returned  to  the 
calling  function. 

In  order  to  permit  the  control  program  to  be  interrupted,  however,  the 
function  termin()  interprets  the  characters  CTRL  S  and  CTRL  Y  specially.  CTRL  S  is 
interpreted  to  mean  "stop  displaying  data  on  the  display  terminal"  if  data  is  being  dis- 
played, or  "start  displaying  data  on  the  display  terminal"  if  the  display  has  already  been 
hailed  by  CTRL  S.    In  other  words,  the  CTRL  S  switch  operates  as  a  toggle  switch  to 


stop  and  start  the  display  of  data.  CTRL  Y  is  interpreted  to  mean  "call  the  diagnostic 
subsystem  menu".  We  do  not  wish  this  to  be  done  more  than  once  at  a  time,  for  oth- 
erwise we  might  make  so  many  recursive  calls  to  the  program  menu()  that  the  stack 
would  be  corrupted. 

The  variable  allo>v_menu_call  will  be  TRUE  the  first  time  termin()  is  called. 
If  CTRL  Y  is  entered,  allow_menu_call  is  set  to  FALSE,  and  further  calls  to  menu()  are 
precluded  thereafter.  It  is  only  returned  to  the  value  TRUE  if  the  menuQ  program  is 
completed  by  the  user  later. 

The  variable  'v>aiting_for_ctls  will  switch  from  FALSE  to  TRUE  or  back 
again  each  time  CTRL  S  is  entered  by  the  user.  Data  from  the  keyboard  will  only  be 
accepted  when  this  variable  is  FALSE,  in  which  case  the  display  has  not  been  halted. 

The  variable  ctrl_valid_data  will  be  a  copy  of  the  \ariable 
console_data_available  described  earlier. 

If  no  data  has  been  read  into  the  console  buffer  previously  by  terminO  or 

by  look_ahead().  then  terminO  will  wait  until  a  character  is  available.    Once  this  occurs, 

the  variable  console_data_available  is  set  to  FALSE,  since  terminO  has  filled  and  emptied 

the  console  buffer  all  at  once.   A  switch  statement  allows  the  character  to  be  interpreted. 

/.     void  tes  tinputf  void) 

This  subroutine  asks  the  user  to  specify  a  port  address  in  hexadecimal.    It 
then  reads  a  character  from  that  port  and  displays  it  on  the  terminal. 
J.     void  testoutput(void) 

This  subroutine  asks  the  user  to  specify  a  port  address  in  hexadecimal,  and 
then  asks  for  a  hexadecimal  byte  to  be  sent  to  that  port.  The  data  is  accordingly  output 
to  the  port. 

10.     File  main.c 

a.  void  memory _dump( void) 

This  subroutine  asks  the  user  for  the  first  address  in  memory  whose  con- 
tents he  wishes  to  inspect,  and  for  the  number  of  characters  which  he  wishes  to  see  dis- 
played. It  then  calls  the  subroutine  dump()  to  honor  the  request.  This  function  is  only 
useful  for  very  low-level  debugging  of  the  software. 

b.  void  testio(void) 

This  subroutine  presents  a  menu  permitting  the  user  to  send  data  to  any 
port,  and  to  read  data  from  any  port,  in  the  system.  The  method  of  implementing  a 
menu  is  the  same  as  that  presented  in  the  description  of  the  function  menu()  and  will  not 


be  repeated  here.   For  output  to  a  port,  the  function  testinput()  is  called.  For  input  from 
a  port,  the  function  testoutputO  is  called. 

11.  File  nibrk.s 

a.     char  *mbrk(long  size,  long  *realsize) 

This  subroutine  is  written  in  Z-80  Assembly  language.  It  is  described  in 
[Ref  17:  Compiler  section,  p.  51],  from  which  it  is  drawn. 

12.  File  newio.s 

a.  char  input(char  port) 

This  subroutine  is  written  in  Z-80  Assembly  language.  It  inputs  a  character 
from  a  port  and  returns  it  to  the  calling  function. 

b.  void  output  (char  port,  char  data) 

This  subroutine  is  written  in  Z-SO  Assembly  language.  It  outputs  a  char- 
acter to  a  port. 

13.  File  po\\er.c 

a.  void  poHer_stat  us  (void) 

This  subroutine  returns  the  status  byte  from  the  POWERIN  port.  This 
status  is  described  in  Table  3  on  page  16. 

b.  char  powi'r_\vrite( char  command) 

This  subroutine  issues  commands  to  the  power  circuit  board.  Vahd  com- 
mands are  SSDROFF  and  SSDRON  (to  turn  the  Solid  State  Data  Recorder  ofTand  on); 
VCOOFF  and  VCOON  (to  turn  the  Voltage  Controlled  Oscillator  off  and  on):  ADOFF 
and  ADON  (to  turn  the  .Analog  to  Digital  Converter  board  off  and  on):  MATFOFF  and 
M.ATFON  (to  turn  power  to  the  matched  filter,  launch  detector  and  barometric  switch 
off  and  on):  and  HE.ATOFF  and  HEATON  (to  turn  power  to  the  heater  circuit  off  and 
on). 

.A  command  can  be  executed  by  writing  it  to  the  POWEROUT  port  and 
then  setting  bit  PWRSTROBE  in  port  C,  to  a  1.  A  delay  of  length  PVVRDELAY  is  re- 
quired before  bringing  that  bit  to  0  again.  Another  delay  of  the  same  length  is  then  re- 
quired. These  delays  ensure  proper  functioning  of  the  relays.  Each  bit  in  the  status  byte 
returned  by  the  function  power_statusO  indicates  whether  the  associated  relay  is  on  or 
off.  The  bit  is  0  if  the  relay  is  on;  1  otherwise.  The  pov>er_write()  function  examines  the 
bit  corresponding  to  the  relay  it  attempted  to  switch.  A  TRUE  is  returned  if  the  relay 
is  in  the  desired  position;  FALSE  is  returned  otherwise. 


14.     File  start.s 

This  file  contains  the  controller's  start-up  code.  It  is  written  in  Z-SO  Assembly 
language.  Whenever  the  Z-SO  receives  power,  it  starts  executing  from  location  0x0000. 
The  start-up  code  initiates  the  stack  pointer  to  the  value  STACKTOP  and  then  causes 
a  jump  to  START.  All  other  Z-80  interrupt  locations  are  initialized  such  that  they  cause 
a  jump  to  the  same  location,  since  interrupts  are  not  used  by  the  controller.  At  START, 
the  L\  register  is  initialized  to  0.  This  register  is  used  by  the  C  compiler  to  point  to  pa- 
rameters and  local  variables  within  C  programs. 

Memor>-  may  be  requested  by  C  programs  using  the  mbrk()  function  provided 
with  the  UNI  WARE  C  Compiler.  The  start-up  code  uses  a  variable  MBRKPTR  to 
point  to  the  next  available  address  of  allocable  memory.  Initially  this  variable  is  set  to 
MR.A\I.  a  global  variable  set  in  the  file  \vibro\control\object\spec  to  point  to  the  begin- 
ning of  all  allocable  memon.'.  Once  mbrk()  has  obtained  some  memory,  it  keeps  it.  so 
the  start-up  code  never  needs  to  reclaim  it.  Consequently,  MBRKPTR  can  only  in- 
crease; it  can  never  decrease. 

ZR.\MSZ  is  the  number  of  R.AM  locations  starting  at  ZR^AM  which  are  used 
for  uninitialized,  static  variables  in  the  C  programming  language  subroutines.  The 
start-up  code  writes  zeros  to  all  these  locations,  because  the  C  programniing  language 
specification  is  that  uninitialized  static  and  external  variables  be  initialized  to  0  by  the 
compiler  [Ref  16:  p.  19S]. 

IR„\MSZ  is  the  number  of  R.AM  locations  starting  at  IR.A\I  which  will  contain 
initialized  data.  This  data  is  stored  in  ROM  locations  starting  at  RAM  DATA  at  the 
time  the  program  is  burned  into  RO.VI.  The  start-up  code  copies  it  from  ROM  to  l^AM. 
Finally,  control  is  passed  to  main(),  the  user's  C  program.  If  main()  should  ever  return 
control  to  the  start-up  code,  a  halt  instruction  is  executed.  The  start-up  code  is  adapted 
from  an  example  given  in  [Ref  17:  Compiler  Section,  pp.  13-15.] 


Table   12.     CONTENTS  OF  SUBDIRECTORY  \VIBRO\CONTRLR\BATCH 


File 

Contents 

ASM.  BAT 

This  batch  file  simplifies  the  assembly  of  Z-80  assembly  lan- 
guage source  code.   To  use  it,  type  asm  <  source  filename  >  .s. 
For  example,  to  assemble  the  file  delay.s,  type  asm  delay.s. 
Note  that  the  file  type  need  not  be  s,  but  whatever  it  is.  it  must 
be  present.    Use  of  s  is  recommended  for  clarity.   The  proce- 
dure produces  object  files  in  subdirectory  \vibro\contrlr\object 
and  assembly  code  list  files  in  subdirectory  \vibro\contrlr\list. 
See  the  description  of  the  batch  file  asmlist.bat  for  instructions 
on  how  to  produce  this  listing  file,  which  includes  all  addresses 
supplied  by  the  linker. 

ASML1ST.BAT 

This  batch  file  produces  a  listing  of  the  assembly  language 
source  file  generated  by  the  Z-SO  assembler.   To  use  it.  type 
asmlist    <  filename. filetype  >  .    The  output  is  appended  to  the 
file  \temp\print.    It  can  be  printed  by  use  of  the  batch  file 
promout.bat.    These  listings  mclude  all  global  addresses  sup- 
plied by  the  linker,  provided  \^ibro\contrlr\vibro.out  has  been 
generated  bv  promlink.bat. 

C.BAT 

This  batch  file  simplifies  the  compilation  ofC  source  code.   To 
use  it.  type  c  <  source  file  name  >  .c.    For  example,  to  compile 
the  file  vibro.c.  type  c  vibro.c.    Note  that  the  file  type  need  not 
be  c.  but  whate\er  it  is.  it  must  be  present.    Use  of  c  is  recom- 
mended for  clarity.    The  procedure  produces  object  files  in 
subdirectory  \vibro\contrIr\object  and  assembly  code  list  files  in 
subdirectory  \vibro\contrlr\list. 

See  the  description  of  the  batch  file  asmlist.bat  for  instructions 
on  how  to  print  hsting  files,  which  show  all  addresses  supplied 
bv  the  linker. 

LIST. BAT 

This  batch  file  produces  a  listing  of  any  MS  DOS  file.    To  use 
it.  type  list  <  niename.filetype  >  .   The  output  is  appended  to 
the  file  \temp\print.    It  can  be  printed  by  use  of  the  batch  file 
promout.bat. 

LOADMAP.BAT 

This  batch  file  appends  a  copy  of  the  load  map  into 
\temp\print.    It  can  be  printed  by  use  of  the  batch  file  prom- 
out. bat. 

The  load  map  shows  the  absolute  addresses  at  which  the  eight 
regions  of  code  produced  by  the  compilation,  assembly,  and 
linking  steps  are  placed.    It  is  useful  to  have  this  so  that  you 
know  whether  the  controller  has  enough  RAM  and  ROM  in- 
stalled to  hold  the  output  program.   The  hsting  shows  the 
starting  address  of  each  region  and  the  number  of  bytes  it  oc- 
cupies.   Regions  reset,  code,  const,  string,  and  data  all  must  be 
stored  in  ROM  initially.   Of  these,  only  data  belongs  in  R.AM 
eventuallv,  vet  it  must  be  stored  in  ROM  initiallv. 

The  reason  is  that  it  contains  C  variables  whose  values  have 
been  initialized.    If  they  were  not  stored  in  ROM.  those  values 
would  not  be  available  at  execution  time.  The  start  up  routines 
in  \vibro\contrlr\asmsource\stai-t.s  cause  these  initialized  vari- 
ables to  be  copied  from  ROM  to  their  proper  locations  in 
R.AM.   These  locations  are  those  shown  in  the  load  map. 

Thus,  in  addition  to  the  ROM  space  required  for  the  other  four 
regions,  be  sure  to  allow  enough  room  for  the  data  region  to 
be  loaded  into  ROM.  too.    For  example,  if  there  is  only  one 
SK  ROM  installed  at  location  OxUOUO.  but  the  load  map  shows 
that  more  than  SK  of  ROM  is  required,  then  there  is  insufTi- 
cient  ROVI  in  place.    Either  more  must  be  added,  or  the  pro- 
gram must  be  reduced  in  size.    How  to  load  the  executable 
program  into  ROM  is  described  below  in  2.     Getting  the  Exe- 
cutable Program  into  EPROM  on  page  146. 

PRINTALL.BAT 

This  batch  file  will  produce  a  listing  of  all  source  files,  all  batch 
files,  a  load  map,  and  a  symbol  listing.   The  output  will  be  ap- 
pended to  the  file  \temp\print.   Normally  you  would  first  empty 
this  file  using  readyout.bat.   After  producing  a  complete  listing, 
it  could  be  printed  on  the  printer  using  promout.bat. 

PROMLIXK.BAT 

This  batch  file  simplifies  the  conversion  of  the  object  modules 
into  an  executable  output  program.    To  use  it.  just  type  prom- 
link. 

It  creates  two  output  files.   The  first  of  these  is 
\vibro\contrIr\vibro.out.    It  contains  information  about  the  ad- 
dresses assigned  by  the  linker  to  global  variables.   This  file  is 
used  by  the  batch  file  promsym.bat. 

The  other  file  which  promlink.bat  produces  is  vibro.hex  which 
can  be  loaded  into  an  EPROM. 

PROMOLT.BAT 

This  batch  file  causes  the  file  \temp\print  to  be  printed.   The 
latter  file  contains  the  output  of  the  list,  asmlist.  loadmap.  or 
promsym  batch  file  executions.    It  does  not  erase  \temp\print. 
Use  readyout.bat  to  do  this. 

PRO.\ISYM.BAT 


This  batch  file  appends  a  listing  of  all  the  variables  known 
globally  throughout  the  control  program  to  the  file 
\teinp\print.   These  include  both  C  language  source  code  vari- 
ables. Z-SO  assembly  language  global  symbols,  and  several 
symbols  defined  by  the  linker  specification  file.   This  listing  is 
useful  in  determining  how  variables  have  been  declared  and  in 
finding  the  absolute  addresses  of  symbols.    It  can  be  printed 
by  use  of  the  batch  file  promout.bat. 


This  batch  file  should  be  used  before  using  any  of  the  follow- 
ing: 


1. 

list.bat 

2, 

asmlist.bat 

READY- 

3. 

printall.bat 

OUT.BAT 

4. 

promsym.bat 

5. 

loadmap.bat 

Its  purpo'^e  is  to  empty  the  temporar\'  files  \temp\temp  and 
\teinp\print  prior  to  their  being  used  by  those  other  batch  files. 
Once  u<;ed.  you  need  not  use  it  again  unless  you  have  already 
printed  the  contents  of  the  temporary  file  and  need  it  no  lon- 
ger, or  unless  vou  wi^h  to  di^^card  it  for  '^ome  other  rca^^on. 


C.  PROGRAM  MAI.NTENANCE 

This  section  describes  how  to  compile  a  new  version  of  the  controller  program;  and 
how  to  get  an  executable  version  of  that  program  into  an  EPROM.  A  basic  familiarity 
with  Microsoft  MS  DOS  is  assumed.    The  file  organization  is  described  in  .APPENDIX 

D.  HIER.\RCHICAL  ORGANIZATION  OF  SOFTWARE  FILES  on  page  88. 
1.     Procedures  for  Generating  a  New  Executable  Program 

a.  Compile  the  C  source  files 

For  each  source  code  file  written  in  the  C  language,  type  c  <  filename  >  .c. 

b.  Assemble  the  Assembly  Code  Source  Files 

For  each  source  code  file  written  in  Z-80  assembly  language,  type 
asm    <  filename  >  .s. 

c.  Link  Modules  Together 

Enter  the  command  promlink..  This  links  all  executable  modules  together, 
generating  an  executable  program  module  in  file  vibro.bin  in  subdirectory-  \vibro\contrlr, 
which  becomes  the  current  directory  upon  completion. 
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Table  13.     CONTENTS  OF  SUBDIRECTORY  \VIBRO\CONTRLR\CSOLRCE 


File 

Contents 

BLBBLE.C 

Contains  programs  which  operate  the  bubble  memon.'  module 
on  the  controller  board. 

CLOCK.C 

Contains  programs  which  operate  the  real  tmie  clock  on  the 
controller  board. 

CONVERT.C 

Contains  programs  which  perform  conversion  of  data  from  one 
format  to  another. 

EXPMNT.C 

Contains  programs  which  are  specially  designed  for  use  with 
the  Vibro-acoustic  Experiment.   They  are  not  usable  by  other 
applications,  although  they  might  be  tailored  to  them. 

FPLTC.C 

Contains  the  routine  fputc(). 

GLOBAL.C 

Contains  the  declarations  of  the  few  variables  which  are  de- 
clared with  global  scope  {i.e..  which  are  known  to  all  subrou- 
tines). 

INITIAL. C 

Contains  programs  which  initialize  both  NSCSlUA 
R.A\I-I  O-Timer  chips  on  the  controller  board. 

INOLT.C 

Contams  programs  which  handle  input  from  and  output  to  any 
device. 

MAIN.C 

Contains  the  highest  level  of  programs  which  operate  the  con- 
troller, including  the  C  subroutine  main().  These  include  most 
of  the  menu-driven  routines  which  are  executed  if  there  is  a 
terminal  attached  to  the  controller  when  it  receives  power. 

POWER.C 

Contains  programs  which  operate  the  electrical  power  relay 
board  in  the  controller.  This  board  supplies  power  to  various 
hardware  subsystems. 

2.     Getting  the  Executable  Program  into  EPROM 

a.  Copy  the  Executable  Program  to  a  Diskette 

Place  a  5  1,4  inch  diskette  in  drive  B.  Then  enter  the  command  copy 
vibro.hex  b:.  This  puts  a  copy  of  the  file  vibro.hex  on  the  diskette.  This  file  contains  a 
hexadecimal  format  of  the  code  which,  when  loaded  into  an  EPROM,  will  allow  the 
controller  to  function. 

b.  Prepare  to  Write  E  PRO  Ms 

We  have  acquired  the  Intel  program  PCPP  PC  Personal  Programmer  to 
load  data  into  EPROMs.  Take  the  diskette  to  the  IBM  Personal  Computer  (PC)  with 
the  EPROM  programmer.  This  PC  is  located  in  Space  Lab  #2,  Room  102.  Bullard  Hall, 
Naval  Postgraduate  School.    Be  sure  you  have  enough  EPROMS  available. 


Table   14. 


CONTENTS  OF  SUBDIRECTORY 
\MBRO\CONTRLR\ASMSOURC 


File 

Contents 

BUBRW.S 

This  file  contains  the  routines  bubread(),  bub»rite()  and  bubx- 
fer().   These  routines  had  to  be  written  in  assembly  language 
because  the  compiled  code  would  not  execute  fast  enough  cor- 
rectly to  perform  data  transfers  with  the  bubble  memor>'  con- 
troller.  Each  routine  looks  just  like  a  C  language  subroutine 
to  the  callins  routine. 

DELAY.S 

This  file  contains  a  delay  routine  written  in  Z-80  assembly 
code,  but  it  can  be  called  as  if  it  were  a  C  language  subroutine. 
Its  purpose  is  to  provide  delays  in  multiples  of  10  ms  in  situ- 
ations where  the  hardware  requires  it. 

MBRK.S 

This  is  a  routine  supplied  with  the  UN  I  WARE  C  compiler.  Its 
purpose  is  to  allow  C  programs  to  request  memory  through  the 
standard  allocation  routines  mallocO  and  calloc() 
[Ref    i:":  Compiler  section,  pp.  5<)-5l]. 

NEWIO.S 

This  file  contains  the  two  routines  input()  and  output().  They 
are  written  in  Z-SU  assembly  code,  but  they  can  be  called  as  if 
they  were  C  language  subroutines.  They  provide  the  ability  to 
read  characters  from  and  write  characters  to  any  valid  port 
address. 

START.S 

This  file  contains  the  Z-80  initialization  code,  such  as  an  ad- 
dress where  execution  should  begin,  interrupt  vectors,  code  for 
initializing  R.A.VI,  and  a  call  to  the  main()  program,  located  in 
the  C  source  file  vibro.c.  It  is  adapted  from  code  provided  bv 
UN  I  WARE. 

To  ensure  they  are  empty,  place  them  in  the  EPROM  eraser  and  turn  on  the 
fluorescent  light  to  erase  their  contents.  While  this  is  going  on,  and  once  the  PC  is 
booted  up,  enter  the  command  cd  pcpp  at  the  command  line.  This  will  make  pcpp  the 
current  subdirecton.-,  and  so  the  program  pcpplod  can  be  issued  to  initialize  the  program 
which  will  write  the  file  vibro.hex  into  the  EPROM s.  Once  this  has  been  done,  enter  the 
command  ipps  channel(3),  which  actually  invokes  PCPP. 

PCPP  now  has  control.   Enter  the  following  commands: 

t  2764  This  command  allows  2764  EPROM s  to  be  used. 

i  80  This  specifies  that  INTEL  8080  hex  format  files  are  being  used. 

This  is  the  format  of  the  program  in  the  file  vibro.he.x. 
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Table   15.     CONTENTS  OF  SUBDIRECTORY  \VIBRO\CONTRLR\HEADERS 


File 

Contents 

BUBBLE.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
bubble.c. 

BUBRW.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
bubnv.s. 

CLOCK. H 

This  file  contains  the  extern  declarations  of  the  routines  in 
clock.c. 

CONVERT.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
convert. c. 

DELAY.  H 

This  file  contains  the  extern  declarations  of  the  routines  in  de- 
lay.s. 

EXPMNT.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
expmnt.c. 

GLOBAL.H 

This  file  contains  the  extern  declarations  of  the  variables  in 
global. c. 

IMTLAL.H 

This  file  contains  the  extern  declarations  of  the  routine  in  ini- 
tial.c. 

IXGLT.H 

This  file  contains  the  extern  declarations  of  the  routines  in  in- 
out.c. 

MAIN.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
main.c. 

NEWIO.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
neMJo.s. 

POWER.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
po^ver.c. 

VIBRO.H 

This  file  contains  definitions  of  all  constants  used  by  the  C 
routines.    It  also  contains  definitions  of  global  structures  used 
throughout. 

This  performs  a  check  to  ensure  the  EPROM  currently  loaded  in 
the  socket  is  blank.  It  should  be  obvious  that  a  blank  EPROM 
must  be  inserted  in  the  slot  before  performing  this  check. 


c:vibro.hex(0000,lffO  t  p 
ctvibro.hex  (2000,3ffO  t  p 
c:vibro.hex  (4000,5ff0  t  p 
cnibro.hex  (6000,6c23)  t  p 
c:vibro.hex  (e000,el27)  t  p  (0c24) 
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The  last  five  commands  copy  the  program  instructions  from  the  diskette  into  the  EP- 
ROM.  The  numbers  in  parentheses  are  the  addresses  which  are  to  be  loaded  into  each 
EPROM.  A  new  EPROM  should  be  mserted  into  the  socket  prior  to  executing  each  of 
the  first  four  commands.  The  number  Ox6c23  m  the  fourth  command  is  one  less  than 
the  number  R.AMDATA  in  the  symbol  table.  The  number  Oel27  is  one  less  than  the 
value  of  ZRAM  in  the  symbol  table.  The  number  0x0c24  is  0x6000  less  than  the  number 
R.-\MDATA  in  the  symbol  table.  This  number  tells  the  PCPP  program  where  in  the  fi- 
nal EPROM  to  begin  writing  this  section  of  data.  Since  the  EPROM  addresses  all  are 
in  the  range  [0x0000,0x1  ffT),  subtracting  0x6000  from  the  actual  starting  address  is  nec- 
essary to  get  the  address  into  the  proper  range.  Note  that  the  last  command  causes  the 
data  which  eventually  will  be  placed  in  R.-\M  to  be  loaded  at  the  end  of  all  the  data 
which  is  to  remain  in  EPROM  locations.  It  is  conceivable  that  this  information  would 
not  fit  onto  the  end  of  a  single  EPROM  but  might  spill  across  the  end  and  require  an- 
other EPROM.  This  would  require  modifying  the  instruction  sequence  shown  above. 
Eor  details,  consult  [Ref  20].  The  command  exit  will  terminate  the  operation  of  the 
PCPP  program. 

This  completes  the  loading  of  the  control  program  into  EPROM.    The  EP- 
ROM s  can  now  be  loaded  into  the  controller  for  testine. 


149 


APPENDIX  H.     CONTROL  PROGRAM  SOURCE  CODE 
A.     FILENAME  SPEC 


Specification  file  for  the  Controller  hardware.   Also  see 
companion  files  "start. asm"  and  "mbrk.asm".   This  specification 
assumes  IZK   of  ROM  at  address  0x0000,  and  8K  of  RAM  at  address  OxeOOO. 

partition  ( 

overlay  { 

region  {)  reset   taddr  =  0]j   /»  reset  vector  */ 

region  {}  code,  const,  stringi     /»  other  ROM  */ 

RAMDATA  =    $i  /*   ROM  to  initialize  region  ram  */ 

Region  ram  is  initialized  at  runtime  startup  by 
copying  data  from  RAMDATA  to  IRAM.   The  data  must 
actually  be  linked  to  its  RAM  address  (IRAM)  to  get 
correct  variable  addresses,  but  must  be 
programmed  into  ROM  here.   By  hand,  you  must 

that  ENDDATA  <=  ENDROM.   ( ENDDATA  is  below » 

ENDROM  =  0x8000 i  /»  end  of  ROM  »/ 


IRAM  =  OxeOOO V 

region  {)  data   [addr=OxeOOO  1  > 

IRAMSZ  =  $  -  IRAMi 


/»  RAM  starts  here.  */ 

/*  RAM  to  be  initialized  on  reset  */ 

/»  «  bytes  to  copy  from  RAMDATA  */ 


ENDDATA  =  RAMDATA  +  ($  -  IRAM)>    /*  compare  this  against  ENDROM  »/ 


ZRAM  =  $> 
region  {)  ram> 
ZRAMSZ  =  $  -  ZRAMj 

MRAM  =  %\ 

region  {)  mbrKram[size=0x250] > 

MRAMSZ  =  $  -  MRAM I 


/*  Pointer  to  start  of  ram  region.  »/ 
/*  RAM  to  be  zeroed  on  reset  */ 
/»  »  bytes  to  zero  on  reset  */ 


/»  RAM  available  to  malloc( )  */ 


region  <)  stack  [size=0x500]> 
STACKTOP  =0x10000 > 
}  o» 
)  p  [size=0xl0000lj 


/»  stack  of  at  least  OxSOO  bytes*/ 
/»  stack  pointer  reset  value  »/ 


B.     FILENAME  VERSION.H 


extern  void  vers ion( void)) 
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C.     FILENAME  VERSION.C 


oid  version! void  )  > 


void  versionl void) 


printf( 
"  n  rControl  program  for  the  Space  Shuitle  Vibro-acoustic  Experiment. 
Version  6.19   April  1^,    1989nr")> 


D.     FILENAME  VIBRO.H 


«define  TRUE  Oxff 
Sdefine  FALSE  0x00 
Rdefine  EXPERIMENTOK  0X11  . 


As  a  parameter  to  menul  1,  this  true  flag 
ts  the  experiment  to  be  run.  */ 


pe 


^define 

SELECT 

0x1 

^define 

ASCII 

0 

«define 

HEX 

1 

^define 

NULL 

0x00  /I 

Rdefine 

BELL 

0x07 

»define 

BS 

0x08 

»def ine 

CTRLS 

0x15 

^define 

CTRLY 

0x19 

Sdefine 

SPACE 

0x20 

^define 

DELETE 

0x7f 

»define 

STANDBY 

0x01 

Sdefine 

SHEEP 

0x02 

Rdefine 

SCROLL 

0x0"^ 

cdefine 

LAUNCH 

0x08 

ttdefine 

RECORD 

0x10 

^define 

PLAYBACK   0x20 

Sdefine 

OPCOMP 

0x<»0 

»define 

NORMOP 

0x80 

Select  appropriate  power  relay.  »/ 
Used  as  a  parameter  to  showbubbuffi  I 
Used  as  a  parameter  to  showbubbuff(  I 
0x00  /*    The  following  are  ASCII  definitions.  */ 


Permits  output  to  be  halted  and  restarted.  */ 
Permits  the  menul  )  program  to  be  entered 
recursively  anytime  console  I/O  taKes  place. 
Only  one  recursive  call  at  a  time  is  supported. 


•  These  are  masks  for  the  SSOR  commands  and. 
'  status  codes.  •/ 


tWefino  TRIES 


/«  Nkjnber  of  times  to  try  something  before  giving  up.  »/ 


»define  BLOCKS_PER_PAGE   2 

/»  The  number  of  data  blocks  per  page 

of  bubble  memory.  »/ 
ffdefine  RECORD.DELAY  12   /»  The  number  of  hours  to  wait  after  initiating 

RECORD  mode  before  daring  to  restart  it.  «/ 

/»  The  following  constants  are  used  by  the  routine  adtoint(  )  to  convert 

values  read  by  the  A/D  converter  into  the  corresponding  real-world  units 
•define  MULT_TEMP     1960784L     /»  urfC  per  unit  on  the  A/D  converter.  »/ 
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^define  MULT_10V  48627<^5L 
»define  MULT_20V   9725490L 

»de-fine  MIN_V0LTAGE_10 

^define  MIN.OPERATING.TEMP 

ttdefino  MIN_DESIRABLE_TEMP 
^define  MAX_DESIRABLE_TEMP 


/*   10E-2V  per  unit  on  the  A/D  converter.  »/ 
/»  10E-2V  per  unit  on  the  A/D  converter.  »/ 

850  /*  8.50  V  is  the  minimum  permissible 

voltage  on  the  lOV  bus.   The  constant 
represents  this  in  units  of  lE-2  V.  «/ 

283  /»  The  bubble  memories  should  not  be  operated 
if  the  temperature  falls  below  10  degrees  C 
or  285  K.  »/ 

285  /*  The  heaters  should  be  on  if  the  temperature 
is  below  285  K.  »/ 

287  /«  The  heaters  should  be  off  if  the  temperature 
is  above  287  K.  */ 


^define  BUBDATA   Ox^iO     /»  I/O  port  for  the  controller's   bubble  memory.  »/ 
«define  BUBCTRL  Ox-il  /*   Control  and  status  port  for  the  BMC.  */ 

/*  The  following  codes  are  commands  to  the  bubble  memory  controller.  »/ 

«define  BABORT        0x19 

»define  BINIT         0x11 

»define  BFIFORESET    OxlD 

»define  BHRBLREG  0x16     /»  Write  boot  loop  register.  »/ 

^define  BREAD         0x12 

^define  BWRITE        0x12 

«define  BLDPARM       OxOb     /*  Load  parametric  registers.  */ 


Sdefine  BTRIES 


30000    /*  Bubble  commands  should  be  written  this  »/ 
/*  many  times  before  giving  up  in  disgust.  »/ 


/»  The  following  are  bubble  memory  controller  status  codes.  »/ 

»define  BBUSY         0x80 

ttdefine  BOPCOMPLETE   0x^0 

«define  BFAIL         0x20 

^define  BTIMING       0x02 

^define  BFIFO        0x01 


^define  BBUSYBIT 

^define  BOPCOMPLETEBIT 

^define  BFAILBIT 

»define  BFIFOBIT 


/»  These  constants  specify  which  bit  in  the  »/ 
/»  BMC  status  bit  is  used  for  which  purpose.  */ 


^define  BNEVER_READY  0 
^define  BXFER_600D 
^define  BXFER.BAD 
ftdefine  PAGELENGTH 
^define  MAXPAGE    8191 


S4    /*  The  ntanber  of  bytes  in  a  page  of  bubble  memory.  »/ 
/«  Greatest  valid  bubble  memory  page  number.  */ 


^define  ADPOINTS  10 


tkJefine  STRLEN 


Mefine  HSTRLEN  2 


^define  HEXINTSTRLEN  ^ 


/»  The  nuwber  of  analog  quantities  to  be  converted  to 

decimal.  */ 
/*   Number  of  characters  to  allow  for  integer 

characters >  including  a  null  terminator.  »/ 
/»  hkonber  of  characters  to  allow  for  hexadecimal 

characters*/ 
/*  Number  of  characters  in  a  hexadecimal  word.  »/ 


^define  DUMPWIDTH  16  /*   Number  of  bytes  in  a  line  of  a  memory  dump.  */ 
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/*   Bi-t  definitions  for  port  C  of  NSC810  «1.  (Base  address  is  0x00.) 
Bit  »    MEANING 
5        Spare  output. 

<►        Power  strobe  output  (Active  high). 

5        One  if  no  terminal  is  connected  to  the  RS-252C  port. 
Zero  if  a  terminal  is  connected. 

2  Barometric  pressure  drop  detection  after  launch 
(active  high). 

1  Vibration  detection  at  la(.r(ch(  active  high). 

0  Matched  filter  detection  of  Auxiliary  Power  Unit  ( APU ) 
prior  to  lau-ich  (active  high). 

»/ 

»define  TERMON   0x08     /*   Points  to  the  terminal  connection  line  in  NSC810  »1, 

Port  C>  Pin  3.  It  is  zero  when  the  terminal  is 

connec  ted . »/ 
«define  BARO_ON   0x0^     /»  Barometric  pressure  drop  line.  »/ 
«define  VIB.ON   0x02     /»  Vibration  detection  line.  »/ 
Sdefine  APU.ON   0x01     /*   APU  detection  line.  »/ 

/»  Bit  definitions  for  port  C  of  NSC810  «2.  (Base  address  is  0x20.) 

Bit  9  Meaning 

5        RESET*  line  for  the  bubble  memory.   This  line  should  be 
zero  whenever  power  is  applied  to  or  removed  from  the 
bubble  menory.   It  is  one  normally.   The  purpose  of 
making  it  zero  during  power  switching  is  to  avoid  havin 
to  meet  the  strict  requirements  for  power  rise  and  fall 
tins  which  would  be  necessary  otherwise. 

<♦        Power  line  for  the  bubble  memory.   This  line  is  a  one 
to  apply  power >  a  zero  to  remove  it. 

3  End  of  analog  to  digital  conversion.   (Active  high?) 

2  Spare  input. 

1  Spare  input. 

0        Heater  control  output  (active  high). 
»/ 

Points  to  the  NSC810  »1, 

Points  to  the  NSC810  «1, 

Points  to  the  NSC810  «1, 

Points  to  the  NSC810  82, 

Points  to  the  NSC810  «2 , 

Points  to  the  power  board  rela 

turn  on  a  peripheral,  you  must  strobe  this  line  high 

for  PHRDELAY  *    10  ms.   This  line  is  NSC810  »1, 

Port  C,  Pin  <♦.  »/ 

/•  These  are  port  addresses  for  the  A/D  converter.  Character  strings  which 
identifiy  these  are  defined  in  file  "global. c".   Be  sure  that  changes 
in  one  place  are  matched  in  the  other.  »/ 

/«  Voltage  from  ^20  V  bus.  »/ 

/•  Voltage  from  -20  V  bus.  »/ 

/»  Voltage  from  +10  V  bus.  »/ 

/»  Temperature  from  shelf  above  BMC.  »/ 

/*   Temperature  from  underside  of  speaker.  «/ 

/»  Terif>erature   from  shelf  above  battery.    */ 

/*  Temperature  from  batteries.  */ 

/»  Temperature  from  controller's  backplane.  •/ 

/«  Temperature  from  card  8  of  BMC.  «/ 

/*  Temperature  from  card  9  of  BMC.  «/ 


Sdefine 

READCl 

0x02 

Sdefine 

BCLRCl 

OxOa 

8def ine 

BSETCl 

OxOe 

Sdef ine 

BCLRC2 

Ox2a 

Sdefine 

BSETC2 

0x2e 

cdefine 

PWRSTROBE  OxK 

Port  C, 

R/H  register. 

Port  C, 

Clear  registei 

Port  C, 

Set  register. 

Port  C, 

Clear  registei 

Port  C, 

Set  register. 

i    relay 

strobing  line. 

©define 

VOLTO 

0x80 

Sdefine 

VOLTl 

0x81 

»define 

V0LT2 

0x82 

•define 

TEMPO 

0x83 

Wdefine 

TEMPI 

0x8^ 

«define 

TEMP2 

0x85 

»define 

TEMP3 

0x86 

»defino 

TEMP'* 

0x87 

Sdefine 

TEMPS 

0x88 

Sdefine 

TEMP6 

0x89 

»define  PHRDELAY 


^define  BUBPWR 


Mofine  BUBOELAY 


2  /*  The  number  of  10  ms  units  that  the  power  board 

strobe  should  be  applied  to  turn  on  a  relay.  »/ 
x20     /»  Points  to  the  RESET*  line  in  h4SC810  «2,  Port  C, 

Pin  5.  »/ 
xlO     /»  Points  to  the  bubble  power  line  in  NSC810  »2, 
Port  C,  Pin  <*.    */ 
5  /*  Number  of  10  ms  units  to  wait  when  operating  the 
bubble  memory.  »/ 


»define  MDRl 
ffdefine  ODRAl 
ffdefine  DDRBl 
«define  DDRCl 
«define  TMOl 
»define  TOLBl 
»define  TOHBl 
«define  STARTOl 
^define  MDR2 
Wdefine  DDRA2 
^define  DDRB2 
Sdefine  DDRC2 
ftdefine  TM02 
^define  T0LB2 
»define  T0HB2 
^define  START02 


0x07 
OxO<+ 
0x05 
0x06 
0x18 
0x10 
0X11 
0x15 
0x27 
0x24 
0x25 
0x26 
0x38 
0x30 
0x31 
0x35 


/»  See  the  documentation  for  a  description  of  the  »/ 
/¥t   use  of  these  ports.  »/ 


^define  PRTDATA  OxcO 
«define  PRTCTRL  OxeO 


for  data  from  RS-232C  interface.  »/ 
for  control  information  from  RS-232C 


/*  Port  numbei 
/*  Port  numbei 
interface.  »/ 
^define  PRTOUTRDY  0x01   /»  Bit  zero  of  the  PRTCTRL  byte  is  a  one  if  the  pri 
is  ready  to  accept  data  and  zero  otherwise.  */ 
ffdefine  PRTRDY   0x02    /»  Bit  one  of  the  PRTCTRL  byte  is  a  one  if  there  is 

data  to  be  read  and  zero  otherwise.  «/ 
/»  Bit  meanings  for  the  power  status  byte  at  address  POHERIN. 
Bit  ff    Meaning 

5        1  if  heater  circuit  is  offj  0  if  it's  on. 
k  1  if  matched  filter  ( APU  detection)  circuit  is  off> 

0  if  it's  on . 
3        1  if  analog  to  digital  converter  ( A/D  )  circuit  is  offj 

0  if  it's  on. 
2        1  if  voltage  controlled  oscillator  (VCO)  is  off> 

0  if  it's  on. 
1        1  if  solid  state  data  recorder  (SSDR)  is  off> 
0  if  it's  on. 


The  same  bit  assignments  apply  to  the  power  command  byte  at  address  P0NER01JT> 
but  the  bits  have  a  different  meaning.   A  one  in  bits  1-5  is  used  to  select  the 
corresponding  relay.   A  zero  is  used  to  cause  that  relay  to  be  ignored. 
A  one  in  bit  zero  causes  the  selected  relays  to  be  switched  on.   A  zero  in 
bit  zero  causes  the  selected  relays  to  be  switched  off. 
»/ 


^define  PWR_RELAYS    5 
ffdefine  POWEROUT  0x01 


/»  The  number  of  power  relay  switches.  »/ 
/*  Port  address  for  power  control  board  ( 


«define 
^define 
»def ine 
Rdefine 
Udaiine 
?J  define 
^define 
Marina 
«define 
ftdefina 
«defina 
»def ine 
»define 
»define 


POWERIN 

SSDROUT 

SSDRIN 

SSDROFF 

SSDRON 

VCCXJFF 

VCOON 

ADOFF 

AOON 

MATFOFF 

KATFON 

HEATOFF 

HEATON 

Ot«IT 


»de-fine  NOPOWER 


0x21     /»  Port  address  for  power  control  board  status.  */ 
0x00     /*   Port  address  for  SSDR  commands.  */ 
0X01     /»  Port  address  for  SSDR  status.  »/ 
0x02  /»  The  following  are  commands  for  applying  or  removing*/ 
0x05  /»   power.*/ 
0x0<» 
0x05 
0x08 
0x09 
0x10 
0x11 
0x20 
0x21 
0x01  /»  The  lowermost  bit  of  a  power  command  is  1  to  turn 
power  on»  0  to  turn  it  off.  »/ 
OxCl    /»  Mask  for  upper  2  bits  and  bit  0  in  power.   These 
bits  have  no  meaning  when  you  examine  the  power 
board's  status.*/ 


/*  These  are  event  codes  used  for  logging  events.  */ 

/*  Dont'  alter  these  codes  without  adjusting  show_event(  )  accordingly. 


/»  A  pre 
A  pre 
A  pre 
A  pre 

«def 


ic  C  means  COMMAND  ISSUED. 

ix  CF  means  COMMAND  FAILED. 

ix  CS  means  COWIAND  SUCCEEDED. 

ix  D  means  SOMETHING  WAS  DETECTED  OR  DONE. 


»/ 


»def 
«def 
»def 
Sdef 
«def 
«def 
Sdef 
»def 
-def 


«def 
«def 


»def; 
»def: 
«def : 
»def: 


»def 
»def 
»def 
«daf 
»def 
»def 
9def 
«def 
»dof 

;;def 


ne  INITIALIZE  0    /»  Start  with  aplomb.  »/ 

ne  CSHEEP  1    /*  SSDR  was  commanded  to  enter  SWEEP  mode.  »/ 

ne  CSSWEEP  2    /»  SSDR  accepted  a  SWEEP  command.  «/ 

ne  CFSWEEP  5    /*  SSDR  wouldn't  accept  a  SWEEP  command.  */ 

ne  OSWEEP  ^    /*  The  sweep  was  completed  successfully.  */ 

ne  DAPUON  5    /*  The  auxiliary  power  unit  was  detected  ON.  */ 

ne  CSCROLL  6    /»  SSDR  was  commanded  to  enter  SCROLL  mode.  »/ 

ne  CSSCROLL  7  /»  SSDR  accepted  a  SWEEP  command.  */ 

ne  CFSCROLL  8  /»  SSDR  wouldn't  accept  a  SCROLL  command.  */ 

ne  DLAUNCH  9    /*  A  launch  was  detected.  */ 

ne  CLAUNCH  10   /*  SSDR  was  commanded  to  enter  LAUNCH  mode.  */ 

ne  CSLAUNCH  11  /*  SSDR  accepted  a  LALB^H  command.  »/ 

ne  CFLAUfCH  12  /»  SSDR  wouldn't  accept  a  LALffJCH  command.  »/ 

ne  DPRESSURE  13   /»  The  pressure  switch  detected  a  pressure  drop.*/ 

ne  DNOOPCOMP  !<♦   /*  SSDR  didn't  report  completion  in  the 

allotted  time.  */ 

ne  DOPCOMP  15   /*  SSDR  completed  its  SWEEP  or  LAUNCH  mode.  */ 

DABORT  16   /*  He  think  the  mission  was  aborted.  »/ 

CONSSDR  17   /»  The  SSDR  power  on  command  was  issued.  »/ 

ne  CSONSSDR  18  /*  The  SSDR  power  on  command  succeeded.  */ 

na   CFONSSDR  19  /»  The  SSDR  power  on  command  failed.  »/ 

ne  COFFSSDR  20   /»  The  SSDR  power  off  command  was  issued.  »/ 

ne  CSOFFSSDR  21   /*  The  SSDR  power  off  command  succeeded.  */ 

CFOFFSSDR  22   /»  The  SSDR  power  off  command  failed.  »/ 

COFFVCO  25   /»  The  VCO  power  off  command  was  issued.  »/ 

ne  CSOFFVCO  2<»  /»  The  VCO  power  off  command  succeeded.  »/ 

ne  CFOFFVCO  25  /»  The  VCO  power  off  command  failed.  */ 

CONVCO  26   /»  The  VCO  power  on  command  was  issued.  «/ 

CSONVCO  27   /»  The  VCO  power  on  command  succeeded.  »/ 

ne  CFO^A^O  28   /*  The  VCO  power  on  command  failed.  »/ 

ne  COFFAD  29   /*  The  AD  power  off  command  was  issued.  »/ 

ne  CSOFFAD  30   /»  The  AD  power  off  command  succeeded.  «/ 
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UdeiiriB 
«def ine 
?tdef  ins 
^define 
ffdef ine 
«def ine 
«def ine 
^define 
Sdef ine 
4f  define 
ffdef ine 
»def ine 
ffdef ine 
»def ine 
<tdef  ine 
#def ine 
Vdef ine 
#def ine 
«def ine 
^deiine 


CFOFFAD 

GONAD 
CSONAD 
CFONAD 

COFFMATF 
CSOFFMATF 
CFOFFMATF 

CONMATF 
CSONMATF  59 
CFOhfllATF  <+0 

COFFHEAT 
CSOFFHEAT 
CFOFFHEAT 

CONHEAT 
CSONHEAT  45 
CFONHEAT  ^6 
READAD 
TERMINATE 
DUSERNOAPU 
INVALIDCOMMAND  SO  /i 


31  /» 

32  /» 

33  /» 

34  /* 

35  /» 

36  /» 

37  /» 

38  /* 
/»  The 
/»  The 

41  /» 

42  /» 

43  /* 

44  /» 
/»  The 
/»  The 

47  /« 

48  /» 

49  /» 


ftdefine  PRIORLAUNCH   51   /» 


The  AD  power  off  command  failed.  */ 
The  AD  power  on  command  was  issued.  »/ 
The  AD  power  on  command  succeeded.  */ 
The  AD  power  on  command  failed.  »/ 
The  MATF  power  off  command  was  issued.  */ 
The  MATF  power  off  command  succeeded.  »/ 
The  MATF  power  off  command  failed.  »/ 
The  MATF  power  on  command  was  issued.  «/ 
MATF  power  on  command  succeeded.  »/ 
MATF  power  on  command  failed.  »/ 
The  HEAT  power  off  command  was  issued.  */ 
The  HEAT  power  off  command  succeeded.  »/ 
The  HEAT  power  off  command  failed.  »/ 
The  HEAT  power  on  command  was  issued.  »/ 
HEAT  power  on  command  succeeded.  »/ 
HEAT  power  on  command  failed.  */ 
We  read  the  A/D's.  «/ 
Finish  gracefully.  */ 

The  user  terminated  the  wait  for  the  APUs .  */ 
This  code  is  regarded  as  invalid>  and  should 
never  occur.   It  is  provided  to  help  in 
debugging  the  software.  */ 

If  power  is  restored  after  the  launch  has  already 
begun,  then  this  mission  status  is  assigned.  »/ 


^define  CSRECORD  52 
»define  CFRECORD  53 


f  The  RECORD  mode  command  succeeded,  f 
'   The  RECORD  mode  command  failed.  */ 


/*  Various  constants  used  for  setting  the  parametric  registers.  */ 


»define  BBLKLNM 
^define  BBLKLNL 
^define  BMBMSEL 

«define  BENREG 


0x10  /*  Block  length  register  MSB.  64  bytes/page.  ' 
0x01  /*  Block  length  register  LSB.  1  page/transfer 
0x00     /*  Bubble  memory  select  ( MBM  ) .  Only  1  module 

connected.  */ 
0x20     /»  Enable  register.   Polling  mode.  »/ 


^define 

THOUSANDTHS 

0x60 

^define 

HUNDREDTHS 

0x61 

»def ine 

SECONDS 

0x62 

ffdefine 

MINUTES 

0x63 

»define 

HOURS 

0x64 

^define 

WEEKDAY 

0x65 

^define 

DATE 

0x66 

»define 

MONTH 

0x67 

/»  The  ports  for  reading  the  date  and  time.  »/ 


struct  datetime  i 
char    month) 


char 

date( 

char 

hour  J 

char 

minutej 

char 

second  J 

char 

hundredths > 

char 

thousandths \ 

/»   This  structure  contains  binary  coded  »/ 
/»  decimal  data  as  defined  for  the  National  »/ 
/*   Semiconductor  MMS8167A  Microprocessor  »/ 
/»  Real  Time  Clock.  »/ 


struct  idatetime  { 
int  imonth) 
int  idate) 


/*  This  structure  contains  the  same  «/ 

/»  information  as  the  datetime  structure,  but*/ 

/*  in  integer  format.   clockint(  )  takes  care  */ 


int  ihourv  /«  of  converting  from  BCD  to  integer  format.  «/ 

int  iminutej 

int  isecondj 

int  ihundredthsj 

int  i thousandths > 


/»  This  structure  describes  the  uses  of  the  bits  in  the  power  relay  control 


port.    »/ 

struct   power_por 

t_fmt    i 

char 

-.Zi 

char 

heater:l( 

char 

matched.filte 

char 

a_to_d:lj 

char 

vco : 1 i 

char 

ssdr:lj 

char 

relays_on: 1> 

/»  Upper  two  bits  are  not  used.  »/ 
/»  Bit  5  -  designates  the  heater  circuit.  »/ 
/«  Bit  <♦  -  designates  the  matched  filter.  «/ 
/*  Bit  3  -  designates  the  A/D  circuit.  »/ 
/»  Bit  2  -  designates  the  VCO.  »/ 
/*  Bit  1  -  designates  the  SSDR.  */ 
/«  Bit  0  -  1  to  turn  relays  on, 
0  otherwise.  »/ 


/*   This  structure  describes  data  stored  in  page  zero  of  the  controller's 

bubble  memory.  */ 
struct  pageOdata  {        /»  A  template  for  data  in  page  zero  of  the 
controller's  bubble  memory.  »/ 
char  sweepstartedj    /»  FALSE  if  sweep  not  yet  begun. 

TRUE  if  sweep  has  been  started  once.  */ 
char  launchdonei  /»  FALSE  if  launch  has  not  yet  been  detected. 

TRUE  if  launch  has  been  detected.  »/ 
int  page  I  /»  Number  of  next  page  available  for 

log  data.*/ 
char  halfpagei       /*  0  if  top  half  of  next  available  page  is 

empty >  1  otherwise.  */ 
char  full_experiment I  /*  TRUE  if  the  full  experiment  is  to  be  performed, 
FALSE  otherwise.  »/ 
/»  We  need  to  record  the  date  and  time  when  RECORD 
mode  was  last  initiated  if  we  are  not  performing 
the  full  experiment.  */ 
struct  datetime  RECORD_star t_t ime > 


/»  This  structure  describes  data  stored  in  every  blocK  of  a  page  in 
the  controller's 

bubble  memory,  with  the  exception  of  page  zero.  »/ 
struct  log_data  {  /»  A  template  for  logged  data.  »/ 

struct  datetitne  clock)    /»   Time  and  date  of  recorded  data.  »/ 
char  event >  /»  A  coded  event.   See  Udeiine   section  for 

codes .  »/ 
char  atod[ADPOINTSl>  /»  Coded  A/D  readings.   Codes  not  yet  defined.  »/ 


/»  Thi«  structure  has  BLOCKS_PER_PAGE  lofl_data  structures  in  it.  »/ 
struct  full_log_page  { 

struct    log_data   half_page[BLOCKS_PER_PAGE ] i 


enum  pwr_ctnd_modif iars  {/«  Thesa  codes  can  he   given  to  cmdlog( )  for  »/ 

issued       =0,     /*  processing.   They  show  whether  a  power  relay 
succeeded    =  1»     /*   command  was  merely  issued >  or  succeeded  or  »/ 
failed       =2      /«  failed. 


E.     FILENAME  BUBBLE.H 

/»  This  file  contains  global  prototype  declarations  for  the  fur«tions  in 
"bubble. c".  •/ 

em  void  bpageset(  int  page)> 

em  void  bubcmdmenu(void)> 

ern  char  bubinit( void  )  > 

ern  char  bubio(char  command, int  page, char  »buffer)i 

ern  void  bubmenut void ) > 

ern  char  bub_on( void ) > 

ern  void  bub_of f ( void  I > 

ern  char  issububcmd( char  command  )  > 

:ern  void  rdstatregt void ) > 

void  showbubbuf f Ichar  buf fer[ ] ,char  mode)} 

void  testpattern( char  buffer[])> 


F.     FILENAME  BUBBLE.C 

/*   bubble. c  */ 

»» include  "bubrw.h" 
^include  "vibro.h" 
^include  "convert. h" 
« include  "expmnt.h" 
^include  " incut. h" 
^include  "delay. h" 
Sinclude  "newio.h" 
<?include  "global. h" 

void  bpageset( int  page)} 

vo  i  d  bubcmdmenu (void)} 

char  bubinit( void)} 

char  bubio(char  command, int  page, char  »buffer)} 

void  bubmenul void)} 

char  bub_on(void)}       /»  turn  on  power  to  the  bubble  card  «/ 

void  bub_off(void)}       /»  turn  off  the  power  to  the  bubble  card  »/ 

char  issububcmd(char  command)} 

void  rdstatreg( void)} 

void  showbubbuf f( char  buf f er[ ], char  mode))  /«  display  the  bObble  buffer.  «/ 

void  testpattemlchar  buffer!])}   /«  sets  whole  bUsbla 

buffer  to  character  of  users  choice*/ 


registers,  which  is  what  this  function  does.  */ 
void  bpagesetl  int  page) 
i 

output(BUBCTRL,BLDPARM)j  /*  signal  to  BMC  next  5  bytes  to  data  port 
are  -for  parametric  registers   »/ 

output! BUBOATA.OxCl  )  I     /»  one  page  to  transfer   BLR_LSB  */ 

output! BUBDAT A, 0x10 )>     /»  one  FSA  channel   BLR_MSB  »/ 

output! BUBDATA, 0x20  )  I     /»  Enable  register-enable  read  corrected  data  »/ 

/»  Mask  off  lower  byte  of  page  number.  »/ 

output  I BUBD AT A, page  S  0x00ff)j 

/»  Mask  off  higher  byte  of  page  number,  with  a  zero  MBM.  »/ 

output (BUBD AT A,! page  »  8)  S  OxOOlf  )> 


/^H^»«»^HHHH»«»^H^*•)H^«»*»*#»*  ****»*»«*♦**»»*  »****«*»»**»»*»*»*»*»»»«*«*»»»***««/ 
/»  Select  from  a  menu,  and  issue,  a  command  to  the  bubble  memory.  »/ 
void  bubcmdmenu! void  ) 
C 

char     datav 

static  int   comnandt  ]  =  { 

BABORT,  BLDPARM,  BINIT,  BFIFORESET, 
NULL,  BWRBLREG 

while  !TRUE  K 

printf! "Select  a  command  to  be  issued  to  the  bubble  memory:  nr 
A  Abort  B  Load  parametric  registers  C  Initialize  D  FIFO  Reset  n  r 
E  Transfer  '►O  bytes  of  Oxff.  F  Write  bootloop  register  n  r 

2  Return  to  previous  menu.  nr")v 

data  =  tolowerl termin! ))\ 

printf! "Xc  n  r",data)> 

if  (data  ==  'z' l  returnj 

/*    Issue  bubble  transfer  command.  »/ 
if  (data  ==  'e" )  { 
if  (bubxferl  1 ) 

printf  (  "Transfer  succeeded,  n  r" ) > 
else 

printf ( "Transfer  failed.  nr")> 
continues 


/»  Initialize  parametric  registers  for  page  zero  »/ 
if  (data  ==  'b' )  { 

bpagesetl 0 ) ( 

continues 

) 

/*   Check  for  other  valid  responses  »/ 
if  (data  <  'a'  | |  data  >  'f ' )  { 

printf!"Use  a  valid  letter  please.  nr")» 

cootinuej 
) 

/*   Issue  the  command  indexed  by  the  letter  */ 
if  ( issububcmd( comnandLdata- 'a ' ] ) ) 

printf  (  "Command  succeeded.  nr")j 


ntf( "Command  failed,  r 


/*   This  routine  initializes  the  controller  card's  bubble  memory. 
Return  FALSE  if  unsuccessful i  TRUE  otherwise. 

After  power  is  applied  to  the  bubble  memory,  call  this  routine. 
It  implements  the  flow  chart  on  p^ .    <».9-4.9b  in  BPK  5V75A  Protyping  Kit 
User's  Maual  from  Intel.  */ 
char  bubinit( void ) 
C 

/*  Clear  the  bubble  memory  registers.  */ 
if  ( !issububcmd(BABORT ) )  { 

printf(  "ABORT  command  failed.  nr")i 

return( FALSE  )> 
) 

delaylBUBDELAY)^  /»  Delay  BUBOELAY  *:    10  ms  */ 

bpageset(0)>  /*  Load  the  parametric  registers  of 

the  bubble  memory.  »/ 
if  ( ! issububcmd( BINIT ) )   {        /*  Initialize  bubble  memory  for  use.  */ 

printf I "INITIALIZE  command  failed,  n  r" ) > 

returnl FALSE  I  J 
) 
if  (  «issububcmd(BFIFORESET  )  )  {     /»  Reset  FIFO  buffer.  */ 

printfC'FIFO  RESET  command  failed  in  bubinit(  I.  nr")> 

return( FALSE  )v 
} 

if  (  'bubxferl  ))   {  /*  Write  ^0  Oxff  characters  to  the 

bubble  memory  controller.  »/ 

printf ("<tO  byte  transfer  failed.   Status:   ")> 

rdstatregt  ) s 

return( FALSE  )) 
} 
if  ( ! issububcmd(BHRBLREG  I  )        /»  Put  boot  loop  memory  map  into  BMC.  */ 

returnl FALSE  \\ 
return( TRUE ) >  /*  If  you  got  this  far,  everything 

worked.  »/ 


/•  Perform  normal  input  from  or  output  to  the  bubble  memory 
controller.  */ 

char  bubiolchar  command, int  page, char  »buffer) 

/»  "command"  can  be  BREAD  to  readj  BWRITE  to  write.  »/ 

/*  "page"  is  a  bubble  memory  page  number,  from  0  to  8192.  »/ 

/»  "buffer"  is  a  pointer  to  a  buffer  of  length  PAGELENGTH.  »/ 

int  j>   /»  Cotnters.  »/ 

/*  Do  not  operate  the  bubble  memory  if  the  temperature  is  below 

MIN_OPERATING_TEMP.  */ 
if  ( colder_than( MIN_OPERATING_TEMP ) ) 
re turn( FALSE  )} 


bub_on(  )s 

if  I 'bubinitt  ))  { 

bub_off(  ij 

return! FALSE  )  i 

} 

bpagesetCpage )  >  /*   Set  parametric  registers  for  the  desired  page.  »/ 

if  (command  ==  BREAD)  { 

bubreadi buffer  1  \ 
}  else  if  (command  ==  BWRITE  )  { 

bubwrite( buffer )i 
} 
/»  Wait  for  th>e  BMC  to  finish  emptying  the  FIFO  buffer  and  return 

OPCOMPLETE.  »/ 
for  ( j=0>j<BTRIES(++j )  { 

if  ( input (BUBCTRL)  &  BOPCOMPLETE  ) 
breaK) 
} 
if  ( j  >=  BTRIES)  C 

bub_off ( )i 

printf I "Couldn't  get  an  OPCOMPLETE  from  BMC.   Status:  ")\ 

returnl  FiLSE  )} 
) 

bub_off(  )\ 
/*      printf (  "OPCOMPLETE  received  from  BMC.nr"tv  «/ 

returnl TRUE )>         /«  If  you  got  this  far,  the  I/O  worked!  »/ 


void  bubnenu( void ) 
{ 

char     data> 

static  char  success[  ]  =  { 

"Bubble  was  successfully  initialized  in  bubmemu(  ).  n  r" 
)l 
static  char   failure[ 1  =  { 

"Bubble  couldn't  be  initialized  in  bubmenu(  ).  n  r" 
)  ( 
while  (TRUE  1  { 
printf( 
"A   Turn  bubble  memory  power  on .  n  r 
B   Turn  bubble  memory  power  off.  n  r 

C   Initialize  bubble  memory  for  use  (fully  automatic)  nr 
Be  sure  to  turn  the  bubble  memory  power  on,  first,  nr 
D   Issue  one  of  a  menu  of  commands  to  the  bubble  memory,  n  r, 
E   Enter  data  from  keyboard  into  buffer,  nr 
F   Show  buffer  contents  in  ASCII  format,  nr 
G   Show  buffer  contents  in  hexadecimal  format,  nr 

H   Copy  buffer  contents  to  bubble  memory  (write  bubble  memory),  nr 
I   Copy  contents  of  bubble  memory  to  buffer  (read  bubble  memory),  nr 
J   Display  contents  of  bubble  memory  status  register,  n  r 
Z  Return  to  previous  menu,  n  r"  )  > 

data  =  tolower( termin(  ))i 
printf( "/c  n  r",data)j 
switch(data  ){ 


case  'a  : 

bub_on(  )) 

break > 
case  'b' : 

bub_off(  )i 

break) 
case  'c': 

if  (bubinit( )) 

printf ( success)) 

else 

printf ( failure)) 

break) 
case  'd' : 

bubcmdmcnuC  )) 

break) 
case  'e' : 

testpatterni tempbuf fer )) 

break) 
case  ' f ' : 

showbubbuff{ tempbuf fer, ASCII )) 

breaks 
case  'g' : 

showbubbuff( tempbuf fer , HEX ) ) 

break) 
case  'h' : 

if  ( !bubio(BWRITE,getpagenol  ), tempbuf fer  )  ) 
printf ( "Write  Failed,  n  r"  ) ) 
breaks 
case  ' i ' : 

if  ( !bubio( BREAD, getpagenol  ), tempbuf fer  )  ) 
printf! "Read  Failed,  n  r"  )  > 

break) 
case  ' j ' : 

rdstatregt  )) 

break) 
case  ' z' :    case  'Z' : 

return! 
default: 

printf  ("Use  a  valid  letter,  please,  nr")) 


char  bub_on(void)  /♦*   turn  on  power  to  the  bubble  card  »/ 

{ 

output! BCLRC2,BUBRST))        /»  Apply  a  reset  to  the  bubble  memory.*/ 
output! BSE TC 2, BUBPWR))        /»  Apply  power  to  the  bubble  memory.*/ 
/*  The  following  delays  could  be  100  ms  ! according  to  the  bubble 

documentation)  but  did  not  work,  so  we  used  300  ms.  */ 
delay IBUBDE LAY))         /»  Hait  BUBDELAY  »  10  ms  for  a  response.  «/ 
output! BSETC2,BUBRST))        /»  Remove  reset  signal.  */ 
delay! BUBDELAY))         /*  Wait  BUBDELAY  «  10  ms  for  a  response,  */ 


void  bub_off(void)   /»  turn  off  the  power  to  the  bubble  card  »/ 

i 

issububcmdl B ABORT )v   /»  Issue  the  "abort"  command  to  the  bubble  card.  */ 
outputlBCLRC2,BUBRST )i    /»  Apply  a  reset  signal  to  the  bubble  memory 

before  switching  the  power  off.  */ 
delay (BU80E LAY  )>      /»  Nait  BLSDELAY  »  10  ms  for  a  response.  »/ 
output(BCLRC2,BUBPHR)i    /*   Remove  power  from  the  bubble  memory.  »/ 


/»  Issue  a  command  to  the  bubble  memory  controller.  */ 

char  issububcmd( char  command) 

{ 

int  i  > 

char  status  J 

i=0>     /»  Initialize  this  so  it  has  a  value  even  if  BABORT 

is  the  command.  */ 
/•  Don't  issue  a  command  until  the  BUSY  bit  goes  away.  */ 
if  ( connand  !=  BABORT)  { 

for  ( i=0>i  <  BTRIES>  +  +  i  )  { 

if  (I  inputlBUBCTRL) )  8  BBUSY  ) 
break) 
} 
} 
if  I  i  >=  BTRIESI  { 

printft "Bubble  controller  stayed  busy  indefinitely  in  issububcmdl 
Status:   "li 

rdstatregl  ) ; 
retumi  FALSE  )> 
} 

output! BUBCTRL> command ) > 

/»  Command  is  not  accepted  until  busy  bit  goes  to  one.  */ 
for  ( i  =  0;i  <  BTRIESi++i  K 
status  =  inputlBUBCTRL I > 

if  ((status  S  BBUSY)  ||  (status  S  BOPCOMPLETE  )  ) 
break) 
) 

/»  For  all  commands  except  RESET  FIFO  and  WRITE  BOOTLOOP  REGISTERS, 
you  must  get  a  BUSY  bit  to  consider  that  the  command  was  accepted. 
However,  an  OPCOMPLETE  is  okayj  if  you  get  it,  proceed.   Note: 
this  is  not  the  way  the  documentation  says  to  do  this.   It  says 
you  must  get  BUSY  set  first.   However,  that  didn't  seem  to  work.  */ 
if  ( ( i  >=  BTRIES) 

SS  (command  •=  BFIFORESET)  8S  (command  !=  BHRBLREG) 
SS  (  status  S  BOPCOMPLETE))  { 
printf( "Bubble  command  Xsh  was  not  accepted.   Status:   "> 

ctoh( command  )  )  > 
rdstatreg(  )> 
retum(  FALSE)) 
) 

/*   Wait  for  the  OPCOMPLETE  status  code.  »/ 
for  ( i  =  Oji  <  BTRIES>  +  +  i  )< 

if  ( input (BUBCTRL)  S  BOPCOMPLETE) 
break) 
} 
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printf ( "OPCOMPLETE  -from  BMC  never  occurred  for  command  Xsh.  Status: 

ctoh( command  ) ) j 
rdstatreg(  )) 
return! FALSE  )> 
}  else  C 

return! TRUE  )} 


void  rdstatregC void) 

printf ( "Xs  n  r" ,ctoh( input( BUBCTRL ) ) ) > 


void  showbubbuf f ( char  buf ferC  ]  ,char  mode)  /*  display  the  bubble  buffer. 
ASCII  format  tries  to  print  each  character  as  if  it  were  a 
printable  ASCII  character. 

HEX  format  is  the  correct  option  to  use  if  not  all  characters  are 
printable.  »/ 
/*  Valid  values  for  "mode"  are  ASCII  and  HEX  «/ 


< 


int  j>  /*  Dump  contents  in  an  8  by  8  array.  */ 

for  ( j=0) j<PAGELENGTHi j  +  + )  { 
if  (mode  ==  ASCII  ) 

printf!  ";<c"  ,buf  f  er(  j  1  )> 
else  { 

printf(";<s  ",ctoh(buffer[  j]  )  t> 

if  I  (0  ==  ( j  +  1)  X  8)  as  (  j  !=  0)  ) 

printf( "  n  r"  )j 
} 
) 


void  testpatternl char  buf fer[ ] ) 

/»  sets  whole  bubble  buffer  to  character  of  users  choice*/ 

i 

char     a 

char     s[STRLEN]>   /»  Storage  for  itoal  ).  «/ 

int  ji 

/*  Make  sure  c  has  a  value  before  checking  its  contents.*/ 

c  =  •  O'j 

printf  (  "Specify  up  to  '/.s   characters  to  stuff  into  the  bubble,  n  r" , 

itoa(PAGELENGTH,s))) 
for  ( j=0>j<PAGELEN6THjj**)  < 
if  (c  !=  '  r"  )  { 
c  =  termini  )i 
if  (c  •=  •  r-  )  { 

buffer! j]  =  c\ 
printf I "Xc">c ) j 
}  else 

buffer! j]  =  •  '} 


FILENAME  BLBRW.H 

im  char  bubxfer( void U 

:m  char     bubreadlchar   »b<jffer)v 

irn   char     bubwri tel  char   »bu-ff8r)v 


H.     FILENAME  BLBRW.S 


adenine     TR'JE 
Sdefine    FALSE 


Ox-ff 
0x00 


i    The  definitions  which  follow  are  from  the  file  "vibro  contrlr  headers  bmc  .h" . 
i    Since  they  are  used  by  C  source  code,  they  are  incompatible  with  assembly 
i  code.   Thus  they  are  copied  here  and  all  C  conments  have  been  converted 
»  to  assembly  language  conments. 


Sdefine  BUBDATA  Ox^fO 
Sdefine  BUBCTRL  Ox'+l 
\  The  following  codes  are 
sdefine  BABORT  Oyl<) 
Sdefine  BINIT  0x11 
Sdefine  BFIFORESET  OxlD 
Rdefine  BWRBLREG  0x16 
Rdefine  BREAD  0x12 
Jfdefine  BWRITE  0x13 
»define  BLDPARM       OxOb 


i    I/O  port  for  the  controller's   bubble  memory. 
;    Control  and  status  port  for  the  BMC.  «/ 
commands  to  the  bubble  memory  controller.  »/ 


ite  boot  loop  register 


i    Load  pari 


etric  registers.  »/ 


Sdefine  BTRIES 


30000    V  Bubble  command' 
i    many  times  befi 
The  following  are  bubble  memory  controller  status  code; 
fine  BBL;SY         0x80 

Ox'fO 


should  be  written  this  */ 
e  giving  up  in  disgust.  »/ 


»define  BOPCOMPLETE 
^define  BFAIL 
Itdefine  BTIMING 
tWefine  BFIFO 


0x20 


tklefine  BBUS^BIT     7 

»define  BOPCOMPLETEBIT 

•define  BFAILBIT     S 

Rdefine  BFIFOBIT     0 


These  constants  specify  which  bit  in  the  */ 
BMC  status  bit  is  used  for  which  purpose.  »/ 


•define  BNEVER.READY 
•define  BXFER_GOOD 
•define  BXFER_BAD 
•define  PAGELENGTH 
•define  MAXPAGE 


)  The  number  of  bytes  in  a  page  of  bubble  memory.  »/ 
(  Greatest  valid  bubble  memory  page  number.  »/ 
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jlmplemetrt  in  assembly  code  a  C  routine 
\oi    forty  bytes  of  Oxff  to  the  bubble  mei 
jinitialization. 


3  permit  a  very  rapid  transfer 
ory   controller  during  its 


jchar  bubxfer(void) 

export 

bubxfer 

region 

code 

bubxfer: 

push 

ix 

Id 

ix,0 

add 

ix,sp 

jlssue  a  FIFO  RESET  command 

Id 

a,$BFIFORESET 

out 

($BUBCTRL),a 

Id 

de,Oxffff 

f ifors_busy: 


J  FIFO  RESET  command  code. 


Initialize  a  timeout  counter. 
See  if  the  command  Mas  accepted. 


Move  busy  bit  into  carry  flag. 


c , f  i  f ors t_accepted 


The  busy  bit 
as  accepted. 


if  the  command 


\    Clear  register  a. 
)  See  if  de  is  0. 


3P 


nz,  f ifors_busy 


Id       a,$FALSE 
jp       bxfer_exit 
f iforst_accepted: 
Id       b.'+O 


Id 


xfer 


a, Oxff 

1 $BUBDATA ) 


)  Check  for  busy  bit  again,  since  timeout 

V  not  yet  complete. 

;    Timed  out  without  succeeding,  so 

i    return  with  a  FALSE  condition  code. 

i    We  need  to  transfer  "+0  bytes  of  Oxff 


in       a,($BUBCTRLt 
J  The  transfer  succeeded  if  you  got  an  Op  Complete  code 
i   with  the  FIFO  bit  set,  even  with  the  timing  bit  ibit  1) 


$BTIMING 
$BOPCOMPLETE 


$BFIFO 
i    Yes. 
i    Unsuccessful  transfei 


the  timing  bit. 
Do  we  have  operation  complete? 


bxfer_exit: 
pop 


)  Successful  transfer. 


I Implement  in  assendaly  code  a  C  routine  to  permit  very  rapid  input  of 
}a  page  of  data  from  the  bubble  memory, 
ichar   bubread(char  »buffer) 


export 
import 


bubread 
issububcmd 


region 
bubread: 
IJcomment 
Register 


usage: 

a    Scratch  space, 
be   Constant  1  for  subtractioi 
da   Constant  PAGELENGTH. 
hi   Constant  BTRIES 
be'  char  »buffer. 


Oendcowment 
push     i 


Id 

hl.SBFIFORESET 

push 

hi 

call 

issububcmd 

pop 

hi 

cp 

$FALSE 

JP 

nz.-frok 

Id 

a,SBXFER_BAD 

JP 

exit 

frok: 

Id 

a.SBREAD 

out 

I SBUBCTRL  l,a 

Id 

hl,$BTRIES-l 

Id 

bc.l 

read_status: 

in 

a,l SBUBCTRL  1 

bit 

SBBUSYBIT.a 

jr 

nz.read 

bit 

SBOPCOMPLETEBIT 

jr 

m,read 

bit 

SBFAILBIT.a 

jr 

nz, timeoutl 

Id 

a,SBNEVER_READY 

JP 

exit 

timeootl: 

Id 

JP 
read: 

Id 
read_byte: 

Id 
check_f ifo: 

bit 


i    Access  alternate  registers. 

i    Save  be' 

i    be'  <--  char  »buffer 

i    Return  to  primary  registers. 

J  Issue  the  FIFO  Reset  command  to  the  BMC. 


I Quit  if  this  command  didn't  work. 


i  Issue  the  READ  command  to  the  BMC. 

>  Look  for  BUSY  bit  up  to  BTRIES  times. 

;  Used  for  subsequent  decrements. 

i  Get  status  from  BMC. 

i  Was  the  command  accepted? 

(  Yes >  so  read  a  block  of  data, 

a  >  Not  busy.   Was  operation  complete? 

\  Yes,  so  read  a  block  of  data. 

",  Not  busy,  not  done.   Failed? 

;  Didn't  fail.   Don't  know  why.   Allow  a 

i  timeout. 

\  Did  fail,  so  quit.   Return  function 

i  completion  code  in  register  a. 

J  Reset  the  CARRY  flag. 

i  Have  we  looked  for  a  BUSY  signal  BTRIES 

I  times  yet? 

i  No,  so  try  again. 

V  Yes,    so  we    timed  ocit .    Quit   and   return 

i  function  completion  code  in  register  a. 


de,SPAGELENGTH-l  >  Prepare  to  read  PAGELENGTH  bytes  from  BMC. 
hl,SBTRIES-l      i    Prepare  to  check  FIFO  bit  BTRIES  times. 


a, (SBUBCTRL)      i    Get  status  byte  from  BMC. 
SBFIFOBIT,a       }  Is  the  FIFO  bit  set,  i.e.  FIFO  ready? 
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hi, be 

nc,check_f ifo 
a,$BXFER_BAD 


i  Yes,  so  read  a  byte. 
>  Reset  the  CARRY  flag. 
i    No,  so  try  again  up  to  BTRIES  times. 

i    Never  got  a  FIFO  ready,  so  quit. 


a,($BUBDATA) 


Read  a  byte  from  the  BMC. 


I  be), a  i  Plaee  the  byte  in  the  buffer. 

be  i  Point  to  the  next  position  in  the  buffer. 

a  i  Reset  the  CARRY  flag. 

de,hl  (  Put  contents  of  de  in  hi  to  permit  use  of  sbe. 

hi, be  i  Have  we  read  all  the  bytes  yet? 

de,hl  i  Restore  usual  contents  to  de  and  hi. 

nc,read_byte  i  No,  so  get  another  one. 

a,$BXFER_GOOD  i  Yes,  so  quit.   Return  function  completion 

i    code  in  register  a. 


J  Restore  alternate  registers. 
>  Restore  ix  register. 


jlmplement  in  assembly  code  a  C  routine  to  permit  very  rapid  output  of 
^a  page  of  data  to  the  bubble  memory, 
ichar   bubwrite( char  ^buffer) 

export   bubwrite 
import   issububcmd 
region   code 
bubwrite: 
??comment 

Register  usage: 

a    Scratch  space. 


Constant  1  for  subtr; 
Constant  PAGELENGTH. 
Constant  BTRIES 
char  »buffer. 


Rendcomment 
push     i 


)  Access  alternate  registers. 

i    Save  be' 

J  be'  <--  char  »buffer 


push 
call 
pop 


hl,$BFIFORESET 


issububcmd 


>  Return  to  primary  registers. 

(  Issue  the  FIFO  Reset  command  to  the  BMC. 


jQuit  if  this  command  didn't  work. 


nz.-frokZ 
a,$BXFER_BAD 


a,$BHRITE 
( $BUBCTRL),a 
hl,$BTRIES-l 


write.siatus: 


>  Issue  the  NRITE  command  to  the  BMC. 


i    Look  for  BUSY  bit  up  to  BTRIES  tim< 
)  Used  for  subsequent  decrements . 


a,($BUBCTRL) 

$BBUSYBIT,a 
nz>write 

$BOPCOMPLETEBIT,! 
nz  .write 
$BFAILBIT,a 
nz, timeouts 


i    Get  status  from  BMC. 
\    Was  the  command  accepted? 
)  Yes>  so  write  a  block  of  data. 
J  Not  busy.   Was  operation  complete? 
Yes>  so  write  a  block  of  data. 
Hot   busy>  not  done.   Failed? 
Didn't  fail.   Don't  know  why.   Allow 
i  timeout. 
a,$BNEVER_READY   >  Did  fail,  so  quit.   Return  function 
exits  i    conpletion  code  in  register  a. 


c ,write_status 
,SBNEVER_READY 


>  Reset  the  CARRY  flag. 

i    Have  we  looked  for  a  BUSY  signal  BTRIES 

i    times  yet? 

i    No,  so  try  again. 

i    Yes,  so  we  timed  out.  Quit  and  return 

>  function  completion  code  in  register  a. 


de,5PAGELENGTH-l  \    Prepare  to  write  PAGELENGTH  bytes  to  BMC. 
repare  to  check  FIFO  bit  BTRIES  times. 


check_fifo2: 


hl,$BTRIES-l 

a,( SBUBCTRL) 

$BFIFOBIT,a 

nz ,putbyte 

a  ' 

hi, be 

nc,check_fifoi 

a,$BXFER_BAD 


i    Get  status  byte  from  BMC. 

\    Is  the  FIFO  bit  set,  i.e.  FIFO  ready? 

i    Yes,  so  read  a  byte. 

5  Reset  the  CARRY  flag. 

)  No,  so  try  again  up  to  BTRIES  times. 

i    Never  got  a  FIFO  ready,  so  quit. 


a, (be)  >  Get  the  byte  from  the  buffer. 

($BUBDATA),a  j  Write  a  byte  to  the  BMC. 

be  (  Point  to  the  next  position  in  the  buffer. 

a  i  Reset  the  CARRY  flag. 

de,hl  i  Put  de  into  hi  to  permit  use  of  sbc. 

hi, be  )  Have  we  read  all  the  bytes  yet? 

de,hl  i  Restore  usual  contents  to  de  and  hi 

nc,write_byte  >  No,  so  get  another  one. 

a,$BXFER_GOOD  >  Yes,  so  quit.   Return  function  completion 

i  code  in  register  a. 


i    Restore  alternate  registers. 


I.     FILENAME  CLOCK.H 

/»  This  file  contains  external  prototyping  declarations  of  all  functions  used 
in  "clock. c".  */ 

extern  void  clockint( struct  datetime  »clock>struct  idatetime  *iclock)j 

extern  void  clockreadl struct  datetime  »your_clock ) > 

extern  char  clockcompare( struct  idatetime  »clockl , struct  idatetime  »clock2)v 

extern  void  clocksetC struct  datetime  *clock)v 

extern  void  clocksumt struct  idatetime  »result, 

struct  idatetime  »clockl, 

struct  idatetime  *clock2)> 
extern  void  dump_clockl struct  datetime  *clock)i 
extern  void  rtclvoid)v 

extern  void  show_waketime( struct  idatetime  *waketime)> 
extern  void  testtimeout( void  )  > 
extern  char  timeoutl int  delaytime> int  measure  )  > 


J.     FILENAME  CLOCK.C 

/*  clock.c  »/ 

;f include  "vibro.h" 
^include  "convert. h" 
^include  "inout.h" 
^include  "newio.h" 
?tinclude  "global. h" 

void  clockint( struct  datetime  *clock>struct  idatetime  *iclock)> 

void  clockreadl struct  datetime  *your_clock ) > 

char  clockcompare( struct  idatetime  »clockl , struct  idatetime  *clock2  )  > 

void  clockset( struct  datetime  »clock  )  > 

void  clocksum( struct  idatetime  »result> 

struct  idatetime  *clockl, 

struct  idatetime  *clock2)j 
void  dump_clock( struct  datetime  *clock)) 
void  dump_iclock( struct  idatetime  »clock)) 
void  get_time( struct  datetime  *date_and_time  )  v 
void  rtc(void)j 

void  show_waketiine(  struct  idatetime  •waketime)) 
char  *strcpy(char  »sl>  char  »s2)} 
void  testtimeout( void)) 
char  timeout( int  delaytime,int  measure)) 

static  char  *monthsI 1  =  < 

"**  Invalid  month  »«", "January" , "February" , "March", "April" >"May" >" 
"July" , "August" , "September" , "October" , "November" > "December" 


/»  Convert  a  datetime  structure  to  an  idatetime  equivalent.   This  allows 

arithmetic  to  be  per-formed  on  dates  and  times.  «/ 
void  clocKint( struct  datetime  »clock , struct  idatetime  *iclock) 
{ 

iclock->imonth    =  bcd_int(  olock->inonth  )i 

iclock->idate    =  bcd_int( clock->date ) > 

iclock->ihour     =  bcd_int( clock->hour  )  > 

iclock->iminute   =  bcd_intl  clock->tninute  )  > 

iclock->isecond   =  bcd_intl clock->second  )  v 

iclock->ihundredths  =  bcd_int( clock->hundredths  )  > 

iclock->i thousandths  =  bcd_int( clock->thousandths ) > 


/*  This  routine  fills  a  clock  structure  with  the  current  date  and  time.  */ 

/»  It  will  not  worry  about  the  hundredths  and  thousandths,  but  it  will  attempt 
to  ensure  that  at  least  the  seconds  have  not  changed  between  the  first 
and  the  last  reads  of  the  various  clock  registers.   Thus  the  hundredths 
and  thousandths  should  not  be  regarded  as  accurate,  ever.  »/ 

void  clockreadl struct  datetime  *your_clock  ) 

{ 

int  i^ 

i  =  Oi 
do  { 

your_clock->thousandths  =  input ( THOUSANDTHS  )  > 

your_clock->hundredths  =  input  I  HUNDREDTHS ) v 

your_clock->second    =  input  I  SECONDS  )  i 

your_clocK->minute    =  input! MINUTES ) v 

your_clock->hour  =  input  I  HOURS  I  i 

your_clock->date  =  inputtDATEiv 

your_clock->month     =  inputi  MONTH  I  •, 
}  while  (your_clock->second    !=  input! SECONDS  )  8&  +  +  i  <=  10  *  TRIES  )» 


/»  Conpare  two  clock  times.   Return  TRUE  if  the  first  is  later  than  o 
equal  to  the  second,  FALSE  otherwise.   This  routine  ignores  the 
hundredths  and  thousandths,  since  they  are  inaccurate.  »/ 

char  clockcomparel struct  idatetime  «clockl, struct  idatetime  »clock2  ) 

i 

int  differences 

difference  =  clockl->imonth  -  clock2->imonth> 

/»  This  logic  allows  you  to  decide  January  comes  after  December. 

if  ((difference  ♦  12  )  X  12  <  6 

SS  difference  !=  0)  return( TRUE  )  v 
if  (difference  !=  0)  return! FALSE  )  > 
if  (clockl->idate  <  clock2->idate  )  retum(  FALSE  )> 
if  (clockl->idate  >  clock2->idate  )  return( TRUE  )  j 
if  (clockl->ihour  <  clock2->ihour  )  return( FALSE  )  I 
if  (clockl->ihour  >  clock2->ihour  )  return(  TRUE > > 
if  lclockl->iminute  <  clock2->iminute  )  return( FALSE  I  > 
if  ! clockl->iminute  >  clock2->iminute  )  return! TRUE  )  > 


if  (clockl->isecond  <  clock2->isecond )  return! FALSE  )  > 
return! TRUE  )i 


/*   This  routine  sets  the  real  time  clock, 
void  clocksett struct  datetime  *clock) 


ge't_time(  clock )  > 
output( MONTH ,clock->month ) > 
outputl DATE ,clock->date ) > 
output! HOURS ,clock->hour  )  \ 
outputl MINUTES, clock->minute)) 
output ( SECONDS, clock->second ) ) 


/*  Find  the  sum  of  two  calendar  periods.  */ 
void  clocksum( struct  idatetine  »result, 

struct  idatetime  »clockl, 
struct  idatetime  *clock2  ) 


{ 


int  maxdatej         /*  The  last  valid  date  in  the  month.  »/ 

result->isecond  =  clockl->i second  +  clock2->isecond j 

result->iminute  =  result->isecond  /  bO) 

result->isecond  '/.=   60> 

result->iminute  ♦=  clockl->iminute  ♦  clock2->iminute> 

result->ihour  =  result->iminute  /  60 j 

result->iminute  '/.=   60*, 

result->ihour  ♦=  clockl->ihour  +  clock2->ihour > 

result->idate  =  result->ihour  /  2<+> 

result->ihour  '/.=    2^> 

result->idate  +=  clockl->idate  ♦  clock2->idate> 

result->imonth  =  1  +  ( clockl->imonth  +  clock2->imonth  -  1)  '/.   12  > 

maxdate  =  ( ( result->imonth  ==  ^  )  ||  ( result->imonth  ==  6) 

II  lresult->imonth  ==9)  ||  ( result->imonth  ==  11  1  )  ?  30  :  31i 
/*  The  real  time  clock  makes  no  provision  for  leap  year,  so  leap  years 

are  ignored  in  this  program  (sigh!)  */ 
maxdate  =  ( result->imonth  ==  2 )  ?  28  :  maxdate) 
result->imonth  ♦=  ( result->idate  -  1)  /  maxdate) 
result->idate  =  I*  ( result->idate  -   1)   '/.   maxdatej 
result->imonth  =  1  ♦  ( result->imonth  -   1)   '/.   12> 


/»  Print  a  clock  structure.  »/ 

void  dump_clock( struct  datetime  »clock  ) 

{ 

int  hour,  minute,  second,  date,  month) 

hour  =  bcd_int(clock->hour )) 

minute  =  bcd_int( clock->minute ) > 

second  =  bcd_int( clock->second)) 

date  =  bcd_intlclook->date)) 

month  =  bcd_int(clock->month)) 


printfl  "X02.2d:X02.2d:X02.2d  '/.%   Xd  n  r" 
hour , minute, second, 
monihst  month  >  12  ?  0  :  month  ], 
date 
); 


/*    Print  an  iclock  structure.  */ 

void  d<jTip_iclock(  stnjct    idatetime  *clock) 

{ 

printfl  "/:02.2d.X02.2d:X02.2d  V.%   Xdnp", 

clock ->ihour, clock- >iminute, clock- >i second, 

months [  clock->imonth  >  12  ?  0  :  clock->imonth  1> 

clock->idate 

)  j 


/»**»****»»«»*«**«»««»»**»«»»«*»*«»«»»»*»»*♦*•»************«»»»*»»»**«*»»*«»/ 

void  get_tine( struct  datetime  *date_and_time  ) 

{ 

int  month,  date,  hour,  minute,  second,  maxdatej 

static  char  cr[  ]  =  "  n  r"> 

while  I  TRUE  I  { 

printf( "Month?  ( 1-12  )   "  )> 

month  =  get int I  )  i 

if  (month  >=  1  SS  month  <=  12) 
breaks 

printfl "Invalid  month.   Re-enter  it.nr"); 
} 

printflcr  1; 
maxdate  =  (month  =='♦11  month  ==6)1  month  ==  9  |  |  month  ==  11)  ? 

30  :  31 > 
maxdate  =  (month  ==  2 )  ?  28  :  maxdatej 
while  (TRUE  )  < 

printf("Day?  (1-Xd)   ", maxdate )> 

date  =  getint(  )  ■■, 

if    (date    >=    1    SS    date    <=    maxdate) 
breakj 

printfl " n  rinvalid   date.       Re-enter    it.nr")> 
) 

printf(cr)> 
while    (TRUE)    { 

printf("Hocjr?    (0-23)      "  )  v 

hour   =   getint(  ) > 

if  (hour  >=  0  8S  hour  <=  23) 
breaks 

printfl  "Invalid  hour.   Re-enter  it.nr")> 
) 

printf(cr)> 
while  I  TRUE  )  < 

printfl "Minute?  10-59)   ")> 

minute  =  getintf  ) ; 

if  Iminute  >=  0  S&  minute  <=  59) 


printfl  "Invalid  mirwj-te.   Re-enter  it.  n  r' 
3 

printf (cr ) > 
while  (TRUE)  { 

printf ( "Second?  (0-59)   ")> 

second  =  9etint(  )> 

if  (second  >=  0  ii   second  <=  59) 
break} 

printf  (  "Invalid  second.   Re-enter  it.nr' 
) 

printf(cr)) 

date_and_time->month  =  int_bcd( month ) > 
datQ_and_tirne->date      =  int_bcd(  date  ) ) 
date_and_time->hour       =  int_bcd( hour ) > 
date_and_time->ininute     =  int_bcd(  minute  )  > 
date_and_time->second     =  int_bcd( second  )  > 


/*  This  routine  is  a  menu-driven  collection  of  routines  for  testing  the 

clock  functions.  */ 
void  rtc(void) 

char     dataj 

while  (TRUE )  { 
printf( 
"  n  rReal  time  clock  functions,  n  r  n  r 
A  Read  Clock,  n  r 
B  Set  clock,  n  r 
C   Test  timeout(  )  function,  n  r 
Z  Return  to  main  menu.  nr")j 

data  =  tolower( termin(  )  )  J 
printf ("Xc  n  r",data)> 
switch  (data)  { 
case  'a ' : 

clockread( Sclock I ) 
dump_clock( Sclock ) i 
break) 
case  'b' : 

clockset(Sclock)) 
break) 
case  'c' : 

testtimeoot( )> 
break) 
case  'z' : 

return J 
default: 

printf  ("Use  a  valid  letter  please,  nr" )) 
break ) 
} 


/»  This  routine  displays  the  wake-up  time.  »/ 
void  show_waketimel struct  idatetime  »waketime) 
{ 

char  s[STRLEN]>   /»  String  for  itoa(  )  routine.  »/ 

itoa(  wake  time- >iinonth>s  )  i 

printf I "Wake-up   time    is:        n  rMonth   =   Xs      ",s)i 

itoa(waketime->idate,sl » 

printf  (  "Date    =   /Js      ",s  )> 

itoa( wake time- >ihour,s )> 

printf("Hour  =  '/.s      ">s)> 

itoa(  wake time- >iminute> s  )) 

printf  ("Minute  =   '/.%      "»s)i 

itoa( wake time- >i second, s )> 

printf  (  "Second  =  Xsnr",s)> 


/»  This  routine  is  used  to  test  the  timeoutl  )  function.  »/ 

void  testtimeoutl void ) 

{ 

char     data,        /»  A  character  entered  from  the  keyboard.  »/ 
unitsj       /*   The  units  of  delay.  */ 

int  delay  I       /«  The  number  of  units  of  delay.  »/ 

while  (TRUE  I  { 

printf I "Test  of  timeoutf  )  function,  n  r  n  r 
Specify  time  units  for  delay:  n  r  n  r 
A   Hours  n  r 
B   Minutes  n  r 
C   Seconds  n  r 
2   Return  to  previous  menu,  n  r"  )  > 

data  =  tolower( termin(  ))» 
printf ( "/c  n  r",data  H 
switch  (data  )  ( 
case  'a ' : 

units  =  HOURS> 

break) 
case  'b' : 

(.nits  =  MINUTES* 

break > 
case  'c' : 

limits  =  SECONDS) 

break) 
case  'z' : 

return) 

break) 
default: 

printf ( "Use  a  valid  letter  please,  n  r"  ) ) 

break ) 


printf (" n  rHow  many  Lnits  of  delay  do  you  want? 

delay  =  9etint(  )» 

printf ( "  n  rS tar  ting  delay:  n  r"  ) ) 


clockreadl Sclock )  i 
dump_clock( Sclock  )  i 
timeout ( delay .units  )  i 
while!  ! timeout! NULL, NULL) 
printf! "Delay  complete,  n  r" 
printfl"Xc",BELL)j 
clockreadl Sclock ) > 
dump_clock( Sclock)  J 


) 


/«  This  routine  is  used  to  initiate  a  timeout  sequence,  and  to  test  for 
completion.   To  set  the  desired  delay  time,  the  parameter  "delay" 
should  be  non-zero.   To  test  for  completion,  "delay"  should  be  zero  (NULL). 
When  setting  the  delay  time,  the  function  always  returns  TRUE.   When 
testing  for  completion,  it  returns  TRUE  if  the  time  has  elapsed,  FALSE 
otherwise.  »/ 
char  timeoutt int  delaytime, int  measure) 

/»  "delaytime"  is  the  length  of  the  timeout.  */ 
/*  "measure"  is  the  unit  of  measure  of  time.   This  can  be 
MONTH,  DATE,  HOURS,  MINUTES,  or  SECONDS.  */ 


i 


static  struct  datetime  timenow) 

static  struct  idatetime  itimenow,  waittimej 

/*  Allow  the  user  to  interrupt  by  use  of  CTRL  characters.  */ 
allow_ctrl_interrupts(  )v 

clockreadl Stimenow  )  i 
clock  in t( S timenow , Si  t  imenow  )  > 

if  (delaytime  ==  NULL)  {  /»  If  delaytime  ==  NULL,  then  check  to 
see  if  timeout  period  is  over.  */ 
return! clockcomparet  8  i  timenow , Swaket  ime  )  U 
}  else  {         /*  Otherwise,  set  the  wakeup  time.  «/ 
waittime. imonth  =  waittime. idate  =  waitt ime. ihour 

=  waittime. iminute  =  wa i tt ime . isecond  =  0> 
switch! measure )  C 
case  MONTH; 

waittime. imonth  =  delaytime^ 
breaks 
case  DATE: 

waittime. idate  =  delaytime) 
break) 
case  HOURS: 

waittime. ihour  =  delaytime) 
break) 
case  MINUTES: 

waittime. iminute  =  delaytime) 
break) 
case  SECONDS: 

waittime. isecond  =  delaytime) 
break) 
) 

clocksum( Swaket ime, Sit imenow, Swaittime) ) 
show_waketime( Swaket ime  ) ) 


return; TRUE )> 


K.     FILENAME  CONVERT.H 

/»   This    file   contains   external   prototyping  declarations    for   all    functions 
in   "convert.c".    »/ 

»   char   atohlchar   »ascii)> 

>  unsigned    int   atohexintt char   asciil])> 
1    int   atoi( char   »s  ) ; 
\  char   »bcd_asclchar   bed  )  i 
1    int   bcd_int(char   bed  )  > 
<   char   »ctoh(char   byte)j 
)   char    int_bcdl  int    decimal  )> 
1   char    »itoa( int   n,    char    st])j 
1   char    tolower( int   c  )  > 

>  char    *uitoh( unsigned    int   word  )  j 


L.     FILENAME  CON\ERT.C 

/*   convert.c  •/ 

Sinclude  "vibro.h" 
s include  "inout.h" 
^include  "global. h" 

char  atohlchar  *asciiM 

unsigned  int  atohexint  (  char  asciiN)> 

int  atoi( char  *s  ij 

char  «bcd_ascl char  bed  )  > 

int  bcd_int(char  bed)) 

char  *ctoh(char  byte  )  j 

char  int_bcd(  int  decimal)-, 

char  •itoa(  int  n,  char  s[3)> 

char  tolowerl  int  c  li 

char  *uitoh I  unsigned  int  word)) 

/»  This  routine  converts  a  two-byte  ASCII  string  representing  a  valid 
hexadecimal  byte  into  a  single  hexadecimal  byte.  */ 

char  atohlchar  *ascii) 

/*  "ascii"  is  a  string  representing  a  hexadecimal  byte.  */ 
{ 

int  i> 

char     result)  /»  The  hexadecimal  byte  after  conversion.  »/ 

result  =  Oi 

for  li=0>i  <  HSTRLEN  &S  asciiEi]  •=  NULLj+i-i)  { 

result  •=  16) 

if  (  '0'  <=  ascii[i]  &&    '9'  >=  asciiti]) 
result  ♦=  ascii[i)  -  '0') 


177 


else  if  ( 'a 
result 


<=  asciili]  8S  'f  >=  asciilil) 

:  10  ■•■  asciiE  i  1  -  'a  '  > 


returnC  result ) ) 


/»  This  routine  converts  a  four-byte  ASCII  string  representing  a  valid 
hexadecimal  word  into  a  single  unsigned  integer.  »/ 

/MMKMMX  XX  )(KXKKXX»»»*«XK)<)(K)<I(*»»»»»*»»»*»»M)<)(»M)<)<»»* »»*»«« <tW*»t»»»»»»«»»»iHHHHt/ 

unsigned  int  atohexint( char  ascii[]) 


int  i\ 

unsigned  int  result j  /»  The  hexadecimal  word  after  conversion.  */ 

result  =  0> 

for  (i=0>i  <  HEXINTSTRLEN  8&  asciiti]  !=  NULL>++i)  { 
result  «=  16) 
if  (  '0*  <=  asciiEi]  48  "?'  >=  asciilil) 

result  +=  ascii[i]  -  '0') 
else  if  ('a'  <=  asciiEi]  &&    'f  >=  asciiEi]) 
result  +=  10  ♦  asciili]  -  'a'j 


} 

return( result ) > 


nt  atoilchar 


/*   convert  string  to  integer 


static  int  i 
sign  =  1; 


switch  ( »s )  { 

case  '- ' :  sign  =  -1) 


while  (*s  >=  '0'  SS  *s  <=  '9" )  n  =  10  ^ 
return( sign  »  n )> 


/*  Convert  a  bytf?  of  binary  coded  decimal  data  to  character  string  format.  «/ 
/»  No  check  is  made  to  ensure  that  input  data  really  IS  in  BCD  format.  »/ 
char  »bcd_asc(char  bed)   /*  Tested  March  16,  1987  »/ 


static  char  ascii[3]) 
int  bcdintj 


bcdint  =  OxOOff  S  ((int)  bed))        /»  Convert  to  integer.  »/ 
/*  If  the  tens  digit  is  a  zero,  put  a  blank  in  its  place) 

otherwise,  put  an  ASCII  digit  there.  */ 
asciitO]  =  (OxfO  8  bcdint)  ? 

(0x30  I  (bcdint  >>  ^ )  )  :  '  •  ) 
asciitl]  =  0x50  |  ((bcdint  8  OxOf)))   /»  Get  the  units  digit.  */ 
ascii[2]  =  NULL)  /»  Terminate  the  string  with 

a  null.  »/ 


returnl ascii ) i 


/»  Convert  a  byte  of  binary  coded  decimal  data  to  integer  format.  */ 
/»  ^4o  check  is  made  to  ensure  input  data  really  IS  in  BCD  format.  »/ 
int  bcd_int(char  bed)     /*   Tested  March  16,  1987.  «/ 

/«  "bed"  is  the  BCD  character  to  be  converted.  «/ 
i 

int  bcdint,  result  i 

/»  Take  the  units  by  masking  off  the  tens.  «/ 

/»  Then  throw  away  the  units  and  keep 
the  tens.*/ 

bcdint  =  OxOOff  8  (int)  bcdi 

result  =  OxOOOf  &  bcdint » 

/•Multiply  the  tens  by  10,  and  add  to  result.*/ 

result  +=  10  »  (bcdint  »   <*  ) ; 

return( result ) i 


•»♦*****»*»*»»#«»*♦»»*»»»*»*******»**«»*«»«»**/ 
Convert  a  character  to  hexadecimal  ASCII  string  format.  »/ 
r  «ctohi char  byte ) 

static  char  asci i [ HSTRLEN] > 
int  byteint,  nibble,  basei 

byteint   =  OxOOff  S  ((int)  byte)>     /»  Convert  to  integer.  */ 

nibble  =  byteint  >>  fi  /»  Get  the  tens  digit.  »/ 

/*  Find  out  whether  the  nibble  is  in  the  range  [0-91,  in  which 
case  its  ASCII  representation  starts  at  0x30  ("+8  decimal),  or 
[10-151,  in  which  case  the  ASCII  representation  starts  at 
A  =  0x^1  (65  decimal).   In  the  latter  case,  add  the  value  of  the 
nibble  to  65-10  =  55.  ♦/ 

base  =  (nibble  >=  10 )  ?  55  :  <t8» 

ascii[0]  -   base  *   nibblei 

nibble  =  byteint  S  OxOfi      /•  Get  the  units  digit.  «/ 

base  =  (nibble  >=  10  >  ?  55  :  '+8v 

asciilll  =  base  *   nibbles 

asciilZl  =  NULLj  /*  Terminate  the  string  with 

a  null.  «/ 

return( ascii  )  i 


/*   This  routine  converts  an  integer  to  a  binary  coded  decimal  character. 
Since  99  is  the  largest  legitimate  BCD  number,  the  ar^jment  "decimal" 
is  taken  modulo  100.  »/ 
char  int_bcd( int  decimal) 

/»  "decimal"  is  the  number  to  be  converted.  »/ 
{. 

int  result* 

/»  Make  sure  decimal  is  a  positive  number.  «/ 

decimal  =  (decimal  <  0)  ?  -decimal  :  decimal > 

decimal  /=  100>  /»  If  decimal  is  too  big,  take 


it  modulo  100.  »/ 
result  =  (decimal  /  10)  <<  <+>      /»  Get  the  tens  and  shift  them  into  the 

high  order  half  of  the  byte.  »/ 
result  +=  decimal  X  lOv       /«  Add  in  the  units.  »/ 
return(  ( char )  result  )> 


/»  itoa  -  convert  n  to  characters  in  s. 

This  program  is  from  TOOLWORKS  C/80,  Version  3.1,  by  Walt  Bilofsky.  */ 

char  *itoa( int  n,  char  s[ 1 ) 

{ 

static  int  c>  k) 

static  char  *p,  »q> 

if  ( (k  =  n)  <  0) 

k  =  -kj 
q  =  P  =  s> 
do  { 

*p  +  +  =  k  X  10  +  '0'  > 
}  while  (k  /=  10)) 
if  (n  <  0)  *p++  =  '-' ) 
*p  =  0) 
while  ( q  <  --p )  < 

c  =  *q)  »q++  =  *p>  •p  =  CJ  } 
return  (s)) 


/*  tolower   -   if  the  input  is  in  [A..Z),  convert  to  lower  case 

This  program  is  from  TOOLWORKS  C/80,  Version  3.1,  by  Walt  Bilofsky.  */ 

char  tolower( int  c) 

{ 

if  ( 'A'  <=  c  S8  c  <=  'Z" ) 

return  (c  +  0x20  )J 

return  o 


/»  Convert  an  unsigned  integer  to  hexadecimal  ASCII  string  format.  »/ 
char  »uitoh( unsigned  int  word) 

static  char  asciitHEXIhaSTRLEN  ♦  1]> 
unsigned  int  nibbles 
int  i> 

asciiCHEXINTSTRLEN]  =  NULLv 

for  (i=0>i  <  HEXIhfrSTRLEN)+  +  i)  { 

/»  Get  the  current  nibble,  in  order  from  most  to  least  significant.  »/ 

nibble  =  OxOOOf  S  (word  »  ( <♦  *  (3  -  i)))) 

/»  If  nibble  >=  10,  convert  it  to  a  letter  from  'A'  to  'F'. 
If  nibble  <   10,  convert  it  to  a  letter  from  'C  to  '9'.  »/ 

asciiEi]  =  (nibble  >=  10)  ?  ('A'  ♦  nibble  -10)  :  ('0'  ♦  nibble)) 
} 
return( ascii  )> 


M.     FILENAME  DELAV.H 


/»  This  fila  contains  external  prototyping  declarations  for  all  functions 
in  "delay. s".  •/ 


extern  void  delay( int  n)j 


N.     FILENAME  DELAV.S 

)    delay. s 

t    Adapted  from  a  program  by  Mr.  David  Rigmaiden  of  the 

\         Space  Systems  Academic  Group  at  the  Naval  Postgraduate  School. 

»define  LOOPCOUNT    10^1 


i    Delay  for  n  hundredths  of  a  second. 

(  void   delay! n  I 

i    int    n;  /»  The  number  of  hundredths  ( 


iconds  of  delay  desired. 


export   delay 
region   code 


delay:   push 


LOOPl: 
LOOP 2: 


ix 

t=15T. 

Cause  ix 

to  point 

to  the  fi 

-St  paramet 

ix,<^ 

t=l^T. 

ix,sp 

t=15T. 

c,l  ix+0) 

t  =  l'»T. 

b,(ix  +  l) 

t  =  l<?T. 

de,S LOOPCOUNT 

t=10T. 

JP 

n2,L00P2 

dec 

be 

Id 

a,b 

or 

c 

JP 

nz, LOOPl 

pop 

ix 

ret 

t=  bT.  Count  down  to  zero  in  L00P2. 

t=  ^fT. 

t=  ^T. 

t  =  10T.  Inner  loop  t  =  2'+T. 

t=    6T.    Repeat    LOOPl   i^til    time    is   tp. 

t=   ^T. 

t=  ^J. 

t=10T.    Outer   loop    t=( 34*2<HfLOOPCOUNT )T. 

t  =  l<tT.    Restore    ix   to    its    initial   value. 

t=10T. 

Total  Delay  =(  106  +  (  5<»*2<*»LOOPCOUNT  )*n  )T. 


Solve  n«10  m*  =  (106  +  (  3^+2'*»LOOPCOUNT  )itn  )T  with  T  =  1/f  =  '♦00  ns  to 
gat  n  =  LOOPCOL^fT .  f  =  2.5  MHz.   For  n=100,  LOOPCOUffT  =  10<»1,  leading 
to  a  delay  of  1.0008  s  for  an  error  of  0.08X.   For  n=l, 
this  leads  to  a  delay  of  10.05  ms  instead  of  th>e  100  ms  required,  for 
and  error  of  0 . 5X . 


O.     FILENAME  EXPMNT.H 

ern  char  ad_read( char  )  > 

ern  int  adtoint(char  addata > unsigned  long  multiplier)) 

ern  void  alter_pageO( struct  pageOdata  »  pagezero)> 

char  bad_idea_to_record( char  show  )  > 

char  baro_switch( void  J  J 

char  checkprt( void  )  J 
ern  char  colder_than( int  reference)} 

:ern  void  display_data_page( struct  full_log_page  *   datapage)) 
:ern  void  display_pageO( struct  pageOdata  *   pagezero ) ) 
:ern  void  do_ sweep! void ) > 

void  expmnt( void ) I 
:ern  void  initialize! void) j 
:em  char  listen!  void  ) ) 

char  logeventf char  event)) 

void  log_menu( void)) 

void  read_ad( void )) 

void  shut_down( void )) 

void  shut_down_no_log( void ) ) 
ern  char  ssdrmode! char  mode)) 
ern   char  ssdr_status( void ) ) 

char  voltages_low( void  ) ) 
em  char  we_launched(  void  ) ) 


P.     FILENAME  EXPMNT.C 

/*  expmnt.c  »/ 

^♦include  "vibro.h" 

«includa  "clock. h" 

^include  "convert. h" 

^include  "inout.h" 

^include  "main.h" 

^*include  "power. h" 

^^include  "newio.h" 

^include  "bubble. h" 

^include  "global. h" 

char  ad_read(char  port)) 

int  adtoint(char  addat a, unsigned  long  multiplier)) 

void  alter_pageO( struct  pageOdata  «  pagezero)) 

char  bad_idea_to_record(char  show)) 

char  baro_switch( void)) 

char  checkprtt void)) 

char  colder_than( int  reference)) 

void  display_data_page( struct  full_log_page  »  datapage)) 

void  display_pageOt struct  pageOdata  »  pagezero)) 

void  do_sweep( void ) ) 

void  expinnt!  void)) 

char   initialize! void)) 

char   listen!void)) 

char  logeventlchar  event)) 

void  log_menul void )> 

void  monitor_heaters! void)) 


void  pos t_ launch! void ) > 
void  record! void  )  V 
void  shut_down( void ) > 
void  shu-t_down_no_log(  void  )> 
char  ssdrmode( char  mode  )  > 
char  ssdr_status( void  )  J 
void  short_experimGnt( void )j 
void  show_event( char  event  )> 
char  voltages.lowl void ) > 
char  we_laij->ched(  void  )  > 

/»  This  routine  gets  data  from  the  analog  to  digital  converter.  »/ 
char  ad_read(char  port) 


output!  port  ,0  )  >  /»  You  must  write  to  the  port  before  you 

can  read  it.  »/ 
delayt 1  )> 
return! input( port ) ) > 


/»»»♦»♦»»*♦«•»*«•»»*«♦*•»««♦♦•♦*♦«•»«*♦»••»»*•*»*•«»»»»*»»»»»»«»»»»♦**»»»»#«/ 
/*   This  routine  converts  a  byte  of  data  fron  the  A/D  converter  into  an 

integer.   In  order  to  reduce  the  amount  of  code  generated  by  the  compiler > 
it  uses  no  floating  point  operations. 

The  routine  assumes  that  the  converted  value  lies  on  a  line  which  passes 
through  the  origin  and  whose  slope  (in  some  arbitrary  units)  is  given  by 
the  multiplier.   Consequently,  this  routine  always  converts  value  of  z.er 
to  zero. 

To  obtain  the  correct  multiplier  amounts  to  calculating  the  slope  and 
scaling  it  to  permit  integer  operations  to  succeed. 

For  example,  assume  that  a  value  of  255  in  the  A/0  converter  (the 
maximijn  possible)  represents  15V.   A  difference  of  1  in  the  value 
read  by  the  A/D  converter  represents 

ISV  /  ZS5  divisions  =  58.8235  mV/division. 
Multiply  this  by  1E6  and  round  off  to  get  the  basic  multiplier: 

58.8235  ♦  1E6  =  5882'*. 
Using  this  multiplier  will  give  results  in  units  of  volts.   To  get  units 
of  tenths  of  volts,  say,  increase  the  multiplier  by  a  factor  of  10  to 
568,2^0.   The  result  will  be  an  integer  representing  the  chosen  units) 
the  decimal  point  is  implied  to  be  to  the  left  of  the  rightmost  digit. 

To  avoid  an  overflow  upon  multiplication,  the  multiplier  should 
b«  Kept  less  than 

(2»*32  )/2S5  =  16,8^3,009. 
The  greates  achievable  accuracy  is  obtained  when  the  multiplier  is  scaled 
up  by  multiplies  of  10  as  much  as  possible  without  exceedir>g  this  limit. 
•/ 

int  adtoint(char  addata  ,(.fi  signed  long  multiplier) 
{ 

/»  During  compilation,  this  line  will  be  flagged  because  it  presents 
the  possibility  of  truncation.   The  problem  is  not  serious  as 
long  as  the  limit  on  the  multiplier  is  observed,  as  discussed  above.  */ 
unsigned  long  value)  /«  A  long  integer  version  of  "addata".  »/ 

value  =  (unsigned  long)  addata) 
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returndintt  (((value  *  multiplier)  ♦  500000L  )  /  lOOOOOODlj 


/*   This  routine  allows  the  user  to  alter  the  flags  and  pointers  in  page  zero 
for  the  purpose  of  permitting  program  functions  to  be  tested  thoroughly. 
Use  caution  in  altering  them.  */ 

void  a lter_pageO( struct  pageOdata  »  pagezero) 
{ 

char  data  I  /*  Holds  a  character  from  the  keyboard.  »/ 

char  changes  =  FALSE  >     /*  TRUE  if  the  page  zero  needs  to  be  altered* 
FALSE  otherwise.   We  know  that  no  unsaved 
changes  have  been  made  to  page  0  before  this 
routine  is  invoked,  so  we  set  this  to  FALSE 
initially.  »/ 
/*  Variable  "flag"  is  used  to  permit  the  values  0  and  1  to  be  displayed 

as  FALSE  and  TRUE  respectively.  */ 
static  char  »flag[  ]  =  { 
"FALSE", 
"TRUE" 

/»  Display  this  menu  repetitively  until  choice  Z  is  made.  »/ 
while(TRUE  )  { 
printf( " 
A   Toggle  'sweeps  tar  ted'  flag  from  Xs  to  Xs .  nr 
B   Toggle  'launchdone'    flag  from  V.%    to  Xs.  nr 
C   Alter  value  of  next  available  page  from  OxXx  =  'Ad.   n  r 
D   Alter  value  of  next  available  half  page  from  Xu  to  V.u.   n  r 
E   Toggle  '  f  ull_experiment '  flag  from  '/.%    to  V.% .   nr 
F   Specify  the  ' RECORD_start_time '  (make  this  at  least  12  hours  before  the  n  r 

present  to  permit  RECORD  mode  to  be  initiated.  )  n  r 
Z   Exit  this  menu,  n  r", 

f lag[pagezero->sweepstarted  ?  1  :  0  ], 

f lag[pagezero->sweepstarted  ?  0  :  1  ], 

f lag[pagezero->launchdone  ?  1  :  0  1, 

f lag[pagezero->launchdone  ?  0  :  1  ], 

pagezero->page,  pagezero->page, 

pagezero- >ha 1 f page , 

(pagezero->halfpage  ==  0 )  ?  1  :  0, 

f lag[pagezero->full_experiment  ?  1  :  0], 

f lag[pagezero->full_experiment  ?  0  :  U 

n 

/*  Input  a  character,  convert  it  to  lower  case,  and  display  it.  »/ 
data  =  tolower(  teniiin(  ) )) 
pr  intf  (  "V.c  n  r"  ,data  )  > 
switch  (data)  < 

case  'a':    /*   Complement  the  "sweeps tar ted"  flag.  »/ 

pagezero->sweepstarted  =  !pagezero->sweepstarted) 

changes  =  TRUE  j 

break*   /»  Complement  the  "launchdone  flag.  «/ 
case  'b' : 

pagezero- >launchdooe  =  ! pagezero- > launchdone) 
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changes  =  TRUE > 

breaks 
case  *c':    /»  AsK  the  user  for  a  page  number.   Let  this  be  the 
next  page  used  for  recording  items  in  the  log.  »/ 

pagezero->page  =  getpagenol )> 

changes  =  TRUE} 

breaks 
case  'd':    /*  Complement  the  "half page"  number.  »/ 

pagezero->halfpage  =  (pagezero->halfpage  ==  0 )  ?  1  :  Oi 

changes  =  TRUE  i 

break  1 
case  'e':    /*  Complement  the  "full_experiment"  flag.  */ 

pagezero->full_experiment  =  !pagezero->full_experiment > 

changes  =  TRUE  i 

break  i 
case  'f:    /*   Ask  the  user  for  a  new  "RECOR0_start_time".  «/ 

get_time(S  ( pagezero->RECORD_start_time  )  )v 

changes  =  TRUEv 

break > 
case  'z':     /*   If  any  changes  have  been  nade,  store  them  in  page 
0  and  quit  this  routine.  */ 

if  ( changes  )  { 

if  I !bubiolBWRITE,0,(char  »)  pageO_buf f er ))  { 

printf( "Update  to  page  0  failed,  nr")} 
) 

} 

default: 

printfC'Use  a  valid  letter,  please,  n  r"  )  v 


•»»»»»*»♦•♦»»»»»♦»»»•»»***/ 
/»  This  routine  checks  to  see  when  RECORD  mode  was  last  initiated. 

If  this  time  was  within  the  last  12  hours,  the  routine  returns  TRUE, 

meaning  that  it  is  not  a  good  idea  to  enter  RECORD  mode  now.   This 

will  avoid  a  situation  where  RECORD  mode  is  restarted  in  the  middle 

of  a  mission,  wiping  out  thie  recorded  data,  "show"  must  be  TRUE  to  display 

the  tine  when  RECORD  mode  can  begin.   If  it  is  FALSE,  the  display  is 

char  bad_ idea. to_record( char  show) 
< 

struct  datetime       current_timei 

struct  idatetime  icurrent_time)  /»  Integer  version  of 

current  time.  »/ 
struct  idatetime  istored_time>  /»  Integer  version  of 

stored  time.  */ 
struct  idatetime  iRECORD_delay_time>       /*  Integer  format  of  time  when 

RECORD  mode  can  begin.  »/ 
struct  idatetime  iRECORD_d©lay_ constant >  /*   Integer  format  of  minimum 

time  between  successive 

startings  of  RECORD  mode.  •/ 

iRECORO_dclay_constant . imonth  =  iRECORD_delay_constant . idate  = 

iRECORD_delay_constant. ininute  =  iRECORD_delay_constant . isecond  =  0> 
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iRECORD_delay_constant.ihour  =  RECOR0_DELAYi 

/*  Get  the  current  date  and  time  and  convert  to  integer  format.  */ 

clockreadt  Scurrent_time  )  \ 

clockint( 4current_time,Sicurrent_time)j 


/»  Get  the  date  and  time  stored  in  the  bubble  memory  as  the  last  time 

that  RECORD  mode  was  initiated  and  convert  to  integer  format.  »/ 
clockint( S( pagezero->RECORD_start_time  )  ,8istored_time ) > 

/*   Add  the  two  dates  and  times  to  get  the  next  time  when  RECORD  mode  can 

be  initiated.  «/ 
clocksum( SiRECORD_delay_time>Sistored_time,SiRECORD_delay_constant ) \ 

if  (show)  { 

printfl "Current  time:   ")> 

dump_clock( Scurrent_time  )  \ 

printf("Time  when  RECORD  mode  last  was  begun:   ")} 

dump_clock( 8(page2ero->REC0RD_start_time  )  ^s 

printf("Time  when  RECORD  mode  can  be  begun  again:   ")> 

dump_iclock( SiRECORD_delay_time ) \ 


/*    Return  TRUE  if  the  current  date  and  time  is  less  than  RECORD_DELAY 
hours  after  the  stored  date  and  time.   Otherwise>  return  FALSE.  */ 
ret urn ( clockcompare( SiRECORD_delay_time, Sicurrent_time  )  )  v 


/*  Check  to  see  if  the  barometric  pressure  switch  tripped. 

Make  an  entry  in  the  log  and  return  TRUE  if  so>  return  FALSE  otherwise.  »/ 

char  baro_switch( void) 
{ 

char  addataj  /»  Holds  a  character  from  port  READCl.  */ 

/«  If  the  BARO_ON  bit  of  the  READCl  port  is  TRUE,  then  the  barometric 

switch  has  been  triggered.  »/ 
addata  =  input ( READCl ) i 
if  (addata  S  BARO.ON )  { 

printf(  "Barometric  switch  triggered,  nr")) 
logevent( DPRESSURE  )  s 
) 


/»  This  routine  checks  to  see  if  there  is  a  printer  connected  to  the 
controller.   It  returns  TRUE  if  there  is  one,  FALSE  otherwise.  »/ 
char  checkprt( void) 
t 

/»  If  the  TERMON  bit  of  the  READCl  port  is  0,  then  a  terminal 
is  connected.  In  this  case  return  TRUE)  FALSE  otherwise.  «/ 

return( (  input( READCl ) )  8  TERMON)) 


/»  This  function  displays  the  data  in  page  zero.  »/ 
void  display_pageO( struct  pageOdata  *  pagezero) 
< 

printf ( "Sweepstarted  =  ")i 
if  ( pagezero->sweepstarted ) 

printf ("TRUE  ")\ 
else 

printf ("FALSE  ")i 
printf  (  "LaL^vchdone  =  ")> 
if  (  pagezero- >lai.rK:hdooG  ) 

printf! "TRUE  ")i 
else 

printf ("FALSE  ")\ 
printf ( "Full-expmnt  =  ")v 
if  (  pagezero->full_experitnent  ) 

pnntfl  "TRUE  n  r"  M 
else 

printf( "FALSE  n  r" tj 
printfl"Last  tine  RECORD  mode  was  initiated:  ")i 
d-unp_clock(  8(  pagezero->RECORD_start_time  I  )\ 

printf  ("  n  rNext  page  =  Ox'/.x    =  '/.u    ",         pagezero->page  »pagezero->page  )  J 
printf("Next  halfpage  =  OxXx  =  Xunr",     pagezero->halfpage > 

pagezero->halfpage ) v 


/*  This  function  returns  TRUE  if  the  bubble  memory's  temperature  is  below 

the  reference  value-,  FALSE  otherwise.  »/ 
char  colder_thani  int  reference  ) 
{ 

char  addata>         /»  Holds  a  character  from  the  A/D.  */ 

int   temperature!     /»  The  current  temperature  in  degrees  K.  */ 

/*    Read  in  the  temperature  of  the  bubble  memory.  */ 

addata    =    ad_readi TEMP^  i  V 

temperature  =  adtoint I addata ,MULT_TEMP ) > 

retumi  (  temperature  <  reference)  ?  TRUE  :  FALSE  )i 


/•  This  function  displays  a  page  of  data.  »/ 

void  display_data_page( struct  full_log_page  *datapage) 

{ 

char  addata  >  /»  Holds  a  character  of  data  from  the  A/D.  */ 

int  page)  /»  The  desired  page  rnjnbor.  »/ 

int  halfpage)  /»  The  current  halfpage  number.*/ 

int  i)  /»  Counts  through  the  valid  A/D  addresses.  */ 

int  value)  /»  The  data  from  the  A/D  converted  into  useful 

Li-iits.  «/ 


printf  (  "l*^ich  page  of  data  do  you  want  to  see?nr")) 

page  =  getpagenoi  )) 

if  ( !bobio( BREAD, page, log_buffer)l  { 

printf  (  "Couldn' t  read  page  /u.  nr",page)) 
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return} 
} 

print-f(  "Contents  of  page  Ox'/.x   =  Xd:  n  r"  , page, page  ) » 
for  (halfpage=Oihalfpage  <  BLOCKS_PER_PAGE >+*halfpage  )  { 
printf("Half  page  Xd:  n  r  t" ,halfpage  )  > 
dump_clock(  8( datapage->half_pagelhalfpage  1. clock  )  )i 
show_event(  datapage->half_page[halfpage ] .event  )j 

/*  "adcaption"  is  defined  in  file  "global. c".  »/ 
for  (i=0>i  <  ADPOINTS>**i)  { 

addata  =  datapage->half_page[ half page  1 .atodl i ] > 

printf("X-2<+s=X3.0d=",adcaption[  i), addata  )i 

if  li  <=  2)  {    /»  The  A/D  reading  is  a  voltage,  in  this 

value  =  adtoint( addata, ( i==2 )?MULT_10V  :  MULT_20V)i 

printf("XcX2.0d.X02.0dV  ",( i  =  =  l  )?'-•:'♦'  , 
value/100  ,value/:iOO  )  j 
)  else  {  /*  The  A/D  reading  is  a  temperature,  in  this  cas( 

value  =  adtoint( addata, MULT_TEMP)> 

printfC'/b.OdK   ", value  )> 
} 

/*  Print  two  points  per  line.  */ 
if  { (0  •=  i  /  2)  I  I  i  ==  ADPOINTS  -  1) 

printf ( "  n  r"  )) 


/***»*»**»»»»»»***»**»*»»»«***»»»»»»*»«»»»»»«**»»*****»*»**»*»*»#»*»»**»**»»/ 
/*  This  function  causes  the  "sweep"  to  be  performed.  »/ 
void  do_sweep( void ) 
{ 

printf("Turn  on  SSDR  and  A/D  Converter  and  place  SSDR  in  SWEEP  mode,  n  r"  )  v 
logevent(power_write( ADON)  ?  CSONAD  :  CFONADlj 
logevent(power_write(SSDRON)  ?  CSONSSDR  :  CFONSSDR)> 
logeventl ssdrmodel SWEEP )  ?  CSSWEEP  :  CFSWEEP)} 
printf  ("Wait  10  seconds  before  starting  sweep,  nr")} 
timeout! 10,SECONDS)> 

/*  Wait  for  timeout  or  for  a  key  to  be  pressed.  »/ 
while! Ttimeoutl NULL, NULL)  )  { 
if  ( look_ahead_discardl  )  ) 
break i 
} 

printf! "Turn  on  VCO.   Wait  12  minutes,  n  r"  )  > 
logeventl power_write!VCOON)  ?  CSONVCO  :  CFONVCO)) 
timeout!  15,  MINLTTESIj 
while  (TRUE )  { 

if  Issdr_status(  )  ==  OPCOMP )  { 
logevent(DOPCOMP)> 
breaks 
} 

if  (timeout! NULL, NULL)  ||  look_ahead_discard( ) )  i 
logeventl DNOOPCOMP ) > 
break  J 


printf ( "Sweep  phase  is  over.   Turn  off  VCO,  A/D  Converter,  and  SSDR. 


logevent(power_writelVCOOFF)  ?  CSOFFVCO  :  CFOFFVCOU 
logevent(power_writelSSDROFF)  ?  CSOFFSSDR  :  CFOFFSSOR)l 
logevent(power_write(ADOFF )  ?  CSOFFAD  :  CFOFFAD)> 
logeventlDSHEEP )> 


/»  This  -function  performs  the  Vibro-acoustic  experiment.  »/ 

void  expmnt(void) 

i 

char  mission_statusi  /»  Can  be  DAPUON,  DLAUNCH,  DOPCOMP ,  DNOOPCOMP , 

or  DABORT.   Used  to  control  program  flow.  »/ 


if  ( ! initialize!  ) )  { 

printf ( "The  bubble  memory  log  is  full. 
RLrming  the  experiment  anyway.  nr")j 


/»  Check  to  see  whether  we  should  operate  the  full  experiment  or  not.  »/ 
if  (  ?pagezero->full_eyperiment  )  { 
short_exper iment (  )( 


/»  Check  the  sweepstarted  flag  in  page  zero  of  the  controller's  bubble 
nenory.   It's  TRUE  if  the  sweep  has  been  started  previously* 
false  otherwise.  ♦/ 
if  (  ! ( pagezero->sweepstarted  )  )  C 

printf  (  "Starting  the  sweep.  nr")> 
do_sweep(  I » 
}  else  { 

printf 1 "Sweep  was  done  previously>  so  we're  skipping  it.  nr")» 
) 

/*   Check  the  launchdone  flag  in  page  zero  of  the  controller's  bubble 
memory.   It's  TRUE  if  the  launch  has  already  taken  placej  FALSE 
otherwise.  »/ 
if  ( ! I pagezero->launchdone ) )  { 

/♦  Keep  on  listening,  until  you  detect  either  the  APU,  or  the 
launch.   If  you  run  out  of  time>  assume  the  mission 
was  aborted.  «/ 
printf("We  haven't  launched  yet.   Listening  for  the  APU.  nr")> 
mission_status  =  listenf  )j 

printf ( "Turning  on  the  SSDR,  because  listen!  )  detected  something,  n 
logevent(power_write(ADON)  ?  CSONAD  :  CFONAD)> 
logeventlpower_write(SSDRON)  ?  CSONSSDR  :  CFONSSOR)V 
if  (mission_status  ==  DAPUON)  { 

printf! "APU  is  on.   Initiate  a  10  minute  timeout,  n  r; 
Placing  SSDR  in  SCROLL  mode,  n  r"  )  i 

logeventlssdrmode!  SCROLL)  ?  CSSCROLL  :  CFSCROLDj 
timeout! 10,MINUTES)> 
while  (TRUE  )  { 

if  (we_launched!  )  ==  DLAUNCH)  { 
printf!  "We  launched.  nr"ii 
mission_status  =  DLAUNCHj 
break > 


if  I  titneout(NULL,NULL)  ||  look_ahead_discard(  )  )  { 

printf ( "We  timed  out  and  are  aborting  the  mission,  n  r"  )  t 
mission_status  =  DABORT > 
logevent( DABORT  )  > 
break) 
) 
) 
) 
)  else  C  /»  Launch  was  done  previously.  »/ 
logevent( PRIORLAUNCH ) > 
mission_status  =  PRIORLAUNCH j 

printf  ("We  have  previously  launched  and  are  in  space  now.  nr 
Assume  mission  has  been  successfully  completed,  n  r"  )  j 
) 
if  (mission_status  ==  DLAUNCH )  { 

printf  (  "Putting  the  SSDR  in  LAUNCH  mode,  nr 
Initiating  a  3  minute  timeout .  n  r"  )  > 

logevent(ssdrmode( LAUNCH)  ?  CSLAUNCH  :  CFLAUNCH)> 
timeout( 3, MINUTES )> 
while  (TRUE  )  { 

/»  If  we  haven't  recorded  a  completed  launch,  check  the  barometr: 
switch.   If  it  has  been  triggered,  then  we  should  record  one. 
if  ( ?pagezero->launchdone ) 

baro_switch(  )  > 
if  (ssdr_status(  )  ==  DOPCOMP )  { 

printf ("SSDR  reported  OP  COMPLETE,  n  r"  )  i 
logevent( DOPCOMP)  J 
break  I 
} 
if  ( timeoutl NULL, NULL)  ||  look_ahead_discard(  ) )  { 

printf ("SSDR  never  reported  OP  COMPLETE.   We  timed  out.  n  r"  ) 
logeventt  DNOOPCOMP  )  \ 
break i 


if  (mission_status  !=  DABORT) 
post_ launch!  )  i 


/*   This  routine  reads  page  0  from  bubble  memory  in  order  to  initiate  the 

experiment  properly.  */ 
char  initialize! void) 

int  i)  /*  A  counter  which  permits  more  than  one  attempt 

to  read  the  bubble  memory.  »/ 
char  power_port)  /»  Holds  the  status  of  the  pov*er  subsystem.  «/ 

printf ( "Read  from  page  0  of  the  btijble  memory,  n  r"  )  > 

/*   Attempt  to  read  from  page  0  up  to  BTRIES  times  before  giving  up.  »/ 
for( i=0>!bubio( BREAD, 0,pageO_buffer)  &&  i  <=  BTRIES>++i)> 
display_pageO( pagezero ) \ 
if  (pagezero->page  >  MAXPAGE )  { 
return! FALSE  )» 


for(  i=0-,i  <  BTRIES-,+  +  i  )  < 

if  1 bubioi BREAD,page2ero->page>log_buffer ) )  C 

printf("logeven-t(  INITIALIZE)  n  r")> 

logevent I  INITIALIZE  )  j 

powep_por-t=powep_s'ta-tus(  )> 

if  IVCOOFF  S   power_port)  i 

printft "Turning  the  VCO  power  subsystem  off.  n  r"  )  i 
logevent! power_write(VCOOFF)  ?  CSOFFVCO  :  CFOFFVCO)> 

} 

if  (HEATOFF  S   power_port )  i 

logeventlpower_writefHEATOFF )  ?  CSOFFHEAT  :  CFOFFHEAT)j 
printfl  "Turning  the  heater  subsystem  off.  nr")j 

} 

return! TRUE )i 


returni FALSE  I 


/•  This  fixation  returns  DAPUON  if  the  APU  is  onj  DLAUNCH  if  the  shuttle 
has  Isunc'-edi  FALSE  if  neither  event  is  detected,  but  exit  is  forced  by 
the  pressing  of  any  key  on  the  terminal.  •/ 

char  lister' void  I 

char  portclj  /•  This  holds  the  contents  of  rJSCSlO  SI  port  c . »/ 

printfl "Turning  Matched  Filter  on.   Wait  for  detection  or  a  keystroke,  nr")! 
/•  Turn  on  the  matched  filter,  and  listen  for  the  APU.   If  the  matched 

filter  is  already  on,  this  connand  has  no  effect.  ♦/ 
logevent(power_write(MATFON)  ?  CSONMATF  :  CFONMATFC, 
while  I  TRUE  )  <. 

if  (we.launchedl  )  ==  DLAUNCH) 
returni DLAUNCH  ); 

portcl  =  inputlREADCDj 
if  (portcl  &  APU_ON)  { 

printfl  "APU  detection  occurred.  nr")j 

logevent! DAPUON  )  j 

return! DAPUON  )> 


Exit   this    fux:tion   if  any  key  on   the   terminal    is  pressed. 
( look_ahead_discard(  )  ) 
returni DUSERNOAPU  ) ; 


Log  an  event.  This  fi^^tion  returns  TRUE  if  the  event  was  logged 
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satisfactorily*  FALSE  otherwise.  »/ 
char  logeventCchar  event) 
{ 

int  i>  /»  A  counter.  »/ 

char  »buffer_ptri  /»  A  pointer  into  the  log  page  buffer.  »/ 

char  fullj  /»  TRUE  when  all  available  pages  are 

used  up.  */ 
buffer_ptr  =  log_buffer>  /»  Make  buffer_ptr  point  to  the  start  of 

the  log  buffer.  »/ 
full  =  pagezero->page  >  MAXPAGE) 

/*  If  the  bubble  memory  is  full>  there's  no  point  in  going  on.  Return.  »/ 
if  (full) 

return( FALSE  ^\ 

/*   Blank  out  the  buffer  if  this  is  a  new  page.   This  guarantees  that 
old  data  won't  reside  in  the  upper  half-page  when  the  new  page  is 
written  to  the  bubble  memory.  */ 
if  ( pagezero->halfpage  ==  0)  { 

for  (i=Oii  <  PAGELENGTH>+  +  i  )  { 

(*buffer_ptr++)  =  0x00) 
} 


/*  Fill  the  current  log  block  with  new  data  to  be  logged, 
clockreadl 


lo9_page-> 

half_page[pagezero->halfpage ] .clock 


log_page-> 

half_page[pagezero->halfpage  ]  .event  =  events 

/»  Read  the  A/Ds  and  put  their  contents  in  the  log,  too 
for  (i=0>i  <  ADPOINTS>i++)  { 
log_page-> 

half_page[pagezero->halfpage ] .atod[ i ] 
=  ad_read( adporti i ] ) V 
) 

if  (event  ==  CSSWEEP  ||  event  ==  CFSWEEP)  < 

pagezero->sweepstarted  =  TRUE) 
} 
if  (event  ==  DPRESSURE )  { 

pagezero->laLr>chdone  =  TRUE) 
) 

/»  Write  the  new  page  of  data  to  the  bubble  meinory.  »/ 
bubiol BWRITE )pagezero->page>log_buf fer  ) ) 
if  (pagezero->halfpage  >=  BLOCKS_PER_PAGE  -DC 

if( l+*(pagezero->page))  >  MAXPAGE )  { 

printf(  "Bubble  memory  is  all  used  \jp.\nr")i 
return! FALSE)) 


pagezero->halfpage  =  0) 
}  else  { 


+  ♦( pagezero->halfpage )  i 

} 

/»  Update  page  0  in  the  bubble  memory.  »/ 

bubio( BHRITE ,0,pageO_buf fer ) \ 

return( TRUE  )>  /»  If  you  got  this  far,  you  know  you  haven't  yet 
run  out  of  bubble  memory.  Return  TRUE  to  show 
successful  logging  of  an  event.  */ 


/»  This  routine  provides  a  menu  of  choices  for  examining  or  changing  the 

contents  of  the  bubble  memory.  «/ 
void  log_menu( void) 
< 

char  data>       /*   Holds  a  character  from  the  Keyboard.  */ 

/*   Read  page  0  from  the  bubble  memory.  »/ 
if  (  »bubio( BREAD, 0,pageO_buf fer ) )  { 

printf I "Couidn' t  read  page  O.nr")) 

return  I 
} 

/♦  Display  the  menu  repetitively  until  Z  is  chosen.  »/ 
while  (TRUE  i  t 
printf ( " 
A   Display  page  O.nr 
B   Display  a  page  of  the  log.  n  r 
C   Alter  the  contents  of  page  0.  nr 
Z   Exit  this  menu,  n  r" 
)> 

data  =  tolowerl termini  ))> 
printf  (  "V.o  n  r",data  )  > 
switch  (data)  < 
case  'a ' : 

display_pageO( pagezero  )  \ 
break; 
case  'b' : 

display_data_page( log_page ) \ 
breaks 
case  'c' : 

alter_pageO( pagezero ) > 
break) 
case  'z' : 

return J 
default: 

printf!  "Use  a  valid  letter  please.  nr")( 


/»  This  routine  monitors  the  temperature  of  the  bubble  memory  used  for 
logging  data  and  operates  the  heaters  to  keep  the  temperature  within 
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the  desired  range.  */ 
oid  monitor_heaters( void ) 

char  power_por-t>      /»  Holds  the  status  of  the  power  subsystem.  »/ 

power_port  =  power_status( )i 

/»  If  it  is  cold  enoughs  and  if  the  heater  is  not  yet  oni  turn  it  on.  */ 

if  ( colder. than(MIN_DESIRABLE_TEMP)  SS  (HEATOFF  8  power_port ) )  { 
printfC'Turn  on  the  heaters,  n  r" ) v 

logevent(power_write(HEATON)  ?  CSONHEAT  :  CFONHEAT)> 
return  J 

} 

/*  It  is  is  warm  enough,  and  if  the  heater  is  already  on,  turn  it  off.  */ 

if  (  (  !colder_than(MAX_DESIRABLE_TEMP ) )  SS  (HEATOFF  S   power_port )  )  { 
printf("Turn  the  heaters  off.nr"U 
lo9event(power_write( HEATOFF)  ?  CSOFFHEAT  :  CFOFFHEATIj 


void  post_launch( void ) 
{ 

printf  (  "We 're  shutting  down  all  power.  nr")> 
shut_down( ) i 
while  (TRUE)  { 

printf ( "Reading  A/Ds  every  5  minutes,  n  r" ) ^ 
timeout! 5, MINUTES )i 
while  ( !timeout( NULL, NULL) )  { 
monitor_heaters(  )v 
if  ( !pagezero->launchdone ) 

baro_switch(  )  > 
if  ( looK_ahead_discard( ) ) 
breaks 
) 

logevent( READAD  )j 
if  ( voltages_low(  ))  { 

printf ( "Voltages  are  too  low.   Terminate  the  experiment,  n  r"  )  > 
logevent( TERMINATE )i 
break ( 


/»  This  routine  performs  the  RECORD  phase  of  the  abridged  experiment.  */ 

void  record(void) 

i 

printf ( "Entering  RECORD  mode,  n  r\ 
Turning  on  SSDR  and  A/D  Converter,  n  r"  )  j 

/»  Store  current  time  in  page  0.  This  is  a  record  of  the  time  when 
RECORD  mode  last  was  begun.  The  next  time  logevent( )  is  called, 
the  data  will  actually  be  stored  in  page  0.  »/ 


clockread(  S(  page2ero->REC0R0_star-t_time  )  1  \ 
logevent(power_writel ADON)  ?  CSONAD  :  CFONAD)i 
logevent(power_write(SSORON)  ?  CSONSSOR  :  CFONSSDR)> 
logeventlssdrmodel RECORD)  ?  CSRECORD  :  CFRECORD)> 
printft "Initiating  a  20  minute  timeout .  n  r"  )  > 
timeout  I 20,MINUTES)i 
while  (TRUE)  { 

/»  If  we  haven't  yet  launched,  check  to  see  if  the  barometric 

switches  have  fired  or  not.  »/ 
if  I !pagezero->launchdooe )  i 

baro_switch( ) > 
) 

if  (ssdr_status(  )  ==  OPCOMP )  i 
logevent(DOPCOMP)> 
breaks 
} 

if  ( timeout  I  NULL, NULL )  ||  look_ahead_discardl  ) )  £ 
logeventl DNOOPCOMP ) j 
break  I 


printf( "Record  phase  is  over.   Turn  off  A/D  Converter  and  SSDR.  nr 
logeventl power_write( SSDROFF  )  ?  CSOFFSSDR  :  CFOFFSSDR)> 
logevent(power_write( ADOFF  I  ?  CSOFFAO  :  CFOFFAD  )  > 


/»  This  routine  operates  an  abbreviated  version  of  the  experiment  which 

avoids  doing  the  "sweep",  and  uses  only  RECORD  mode  in  the  SSDR.  »/ 
void  short_experinent! void  ) 
i 

char  showflag>       /•  This  flag  is  TRUE  to  make  bad_idea_to_record(  ) 

display  computed  tines >  FALSE  otherwise.  »/ 
if  (pagezero->launchdone  )  { 

printf I "We  have  previously  launched  and  are  in  space  now.  n  r"  )  v 
logeventc  PRIORLAUNCH ) \ 


whilel  ?pagezero->laLnchdone  )  { 

/»   If  RECORD  mode  was  initiated  too  recently,  we  don't 

want  to  try  it  again.   Wait  for  a  suitable  interval  to  elapse  before 
continuing.   bad_idea_to_record(  )  knows  how  long  this  is. 
Alternatively,  the  user  can  press  a  key  to  avoid  waiting.  */ 

showflag  =  TRUE)  /•  Have  bad_idea_to_recordl )  display  computed 
times  the  first  time  through.  »/ 

while  ( bad_idea_to_record( showflag) )  i 

showflag  =  FALSE v 

if  ( look_ahead_discard( ) ) 
break) 
) 

/»  Wait  for  indications  of  a  lacrtch.  »/ 
listen!  ) ; 

/»   Enter  RECORD  mode.  »/ 
record! )> 


if  (  !pagezero->launchdor(e  ) 
baro_switch( ) > 
) 

/*   Now  that  we're  in  space >  perform  post-launch  operations. 
post_launch(  )  s 


/*   This  function  displays  the  meaning  of  an  event  code.  */ 
void  show_event(char  event) 

/*  "event"  is  an  index  into  the  following  array  of  messages. 
It  is  one  of  the  event  codes  given  in  the  "vibro.h"  file. 
If  someone  changes  it>  someone  had  better  change  these  messages  to 
correspond,  or  the  results  will  be  disappointing.*/ 
static  char  »messaget  1  =  { 

"Initialization,  n  r"  , 

"Sweep-mode  command  issued.  nr"> 

"Sweep-mode  command  accepted,  r^  r"  , 

"Sweep-mode  command  not  accepted,  nr", 

"Sweep-mode  completion  detected,  nr", 

"APU  detected,  n  r", 

"Scroll-mode  command  issued,  nr", 

"Scroll-mode  command  accepted,  n  r" y 

"Scroll-mode  command  not  accepted,  nr", 

"Launch  detected,  n  r" , 

"Launch-mode  command  issued,  nr", 

"Launch-mode  command  accepted  nr", 

"Launch-mode  command  not  accepted,  n  r" , 

"Barometric  switch  detection,  n  r" , 

"SSDR  did  not  give  OP  COMPLETE  within  the  allotted  time,  n  r" , 

"SSDR  reported  OP  COMPLETE,  n  r" , 

"Mission  abort  inferred.  r\  r"  , 

"SSDR  ON  command  issued,  n  r", 

"SSDR  ON  command  succeeded,  n  r" , 

"SSDR  ON  command  failed,  n  r" , 

"SSDR  OFF  command  issued.  r\  r" , 

"SSDR  OFF  command  succeeded,  n  r" , 

"SSDR  OFF  command  failed,  n  r"  , 

"VCO  OFF  command  issued,  nr", 

"VCO  OFF  command  succeeded,  nr", 

"VCO  OFF  command  failed,  n  r", 

"VCO  ON  command  issued,  n  r" , 

"VCO  ON  command  succeeded,  n  r" , 

"VCO  ON  command  failed,  n  r" , 

"A/D  OFF  command  issued,  n  r" , 

"A/D  OFF  command  succeeded,  n  r", 

"A/D  OFF  command  failed,  nr", 

"A/D  ON  command  issued,  n  r" , 

"A/D  ON  command  succeeded,  n  r", 

"A/D  ON  command  failed,  nr", 

"MATCHED  FILTER  OFF  command  issued,  nr", 

"MATCHED  FILTER  OFF  command  succeeded,  n  r" , 

"MATCHED  FILTER  OFF  command  failed,  n  r" , 


"MATCHED  FILTER  ON  command  issued,  n  r" , 

"MATCHED  FILTER  ON  command  succeeded,  nr", 

"MATCHED  FILTER  ON  conmand  failed,  n  r" , 

"BUBBLE  MEMORY  HEATER  OFF  command  issued,  n  r" , 

"BUBBLE  MEMORY  HEATER  OFF  command  succeeded,  nr", 

"BUBBLE  MEMORY  HEATER  OFF  command  failed,  nr", 

"BUBBLE   MEMORY    HEATER   ON  coflmand    issued,  n  r" , 

"BUBBLE  MEMORY  HEATER  ON  command  succeeded,  nr", 

"BUBBLE  MEMORY  HEATER  ON  command  failed,  nr", 

"READ  A/D  command  issued,  n  r" , 

"Experiment  terminated,  n  r" , 

"User  interrupted  the  wait  for  APU  detection n  r. " , 

"Invalid  command,  n  r" , 

"Launch  occurred  before  the  last  program  initialization. 

"RECORD  node  command  to  SSDR  succeeded,  n  r", 

"RECORD  mode  command  to  SSDR  failed,  nr." 

printf 1  message! event  ]  )  j 


/♦»*«*♦*»«»***»*♦««*»»**•»«»*♦»•»»»»»»»»»»»»»»»«»»»*»*»»♦«««»*#*»«»**»**»*»»/ 
/*   This  routine  removes  power  from  any  relays  which  have  it,  and  logs  the 

fact.  »/ 
void  shut_down( void ) 
< 

char  power_port>      /»  Holds  the  status  of  the  power  subsystem.  */ 
power_port  =  power_statusl  )j 

/•  Renove  power  from  all  subsystems  which  currently  have  power.  */ 
if  (SSDROFF  S  power_port  ) 

logevent(power_write(SSDROFF)  ?  CSOFFSSDR  :  CFOFFSSDR)> 
if  (VCOOFF  S   power_port) 

logevent(power_write{ VCOOFF  )  ?  CSOFFVCO  :  CFOFFVCO)> 
if  (AOOFF  S   power_port) 

logeventlpower_write( ADOFF  )  ?  CSOFFAD  :  CFOFFAD)j 
if  (MATFOFF  S   power_port  ) 

logevent(power_write(MATFOFF  )  ?  CSOFFMATF  :  CFOFFMATF)> 
if  (HEATOFF  S   power_port  ) 

logeventlpower_write(HEATOFF)  ?  CSOFFHEAT  :  CFOFFHEAT)> 


/»  This  routine  removes  power  from  any  relays  which  have  it.   It  does  not 

log  the  fact.  •/ 
void  shut_down_no_log( void  ) 
< 

char  power_port>      /»  Holds  the  status  of  the  power  s(±)system.  «/ 
power_port  =  power_status(  )) 
/•  Remove  power  from  all  subsystems.  »/ 
f  (SSDROFF  a   power_port) 

power_write( SSDROFF)} 
f  (VCOOFF  S   power_port) 

power_write( VCOOFF )) 
f  (ADOFF  a   power_port) 

power_wr ite( ADOFF )> 

f  (MATFOFF  a   power_port) 

power_write( MATFOFF)} 


if  (HEATOFF  8   power_port ) 
power_wri-te(  HEATOFF )  > 


/»  This  routine  sets  the  SSDR's  mode.  »/ 

/»  "mode"  is  a  coded  SSOR  node.   See  file  "vibro.h".  »/ 


char  ssdrmode(char  mode) 


int  i\  /»  A  counter.  */ 

char  status  J      /*  Hexadecimal  status >  used  for  debugging.  »/ 

/»  Repeat  the  following  code  several  times  if  the  SSOR  does  not 

immediately  appear  to  be  successful.  */ 
for( i=0>i  <  TRIESi*  +  i  )  i 

outputl SSD ROUT, mode ) >     /*  Output  a  mode  command  to  the  SSDR.  »/ 

/»  Wait  for  the  SSDR  to  respond.  */ 
delay(2)>    /»  Delay  2  x  10  ms  to  get  a  valid 
status.  */ 

status  =  ssdr_status( )i 

if  (status  ==  NORMOP)  { 

/»  Adding  1  to  a  mode  gives  the  code  for  a  successful  operation.  */ 
printf("SSDR  returned  NORMOP  in  response  to  command  OxXx.  n  r" , 

return! TRUE  )> 
) 

/*  The  SSDR  did  not  confirm  the  proper  mode  was  set. 
Try  again.   After  you  give  up  in  disgust,  signal 
failure  by  returning  FALSE.  »/ 
} 

printf("SSDR  did  not  return  NORMOP  in  response  to  command  Ox'/.x.   nr",mode)) 
returnC FALSE )v 


/»  This  routine  gets  the  SSDR's  status. 

char  ssdr_statusl void) 

{ 

return!  ir^sutl  SSDRIN  ) )  j 


/»  This  function  returns  TRUE  if  the  power  supply  voltages  are  too  low) 
FALSE,  otherwise.  »/ 

char  voltages_low( void) 

i 

int  voltage)  /»  Holds  the  voltage  in  hundredths  of  a  volt.  »/ 

char  addata)  /»  Holds  the  voltage  as  read  by  the  A/D.  */ 

/»  Read  in  the  voltage  on  the  lOV  bus.  »/ 

addata  =  ad_read( V0LT2 )> 

/*   Convert  to  hundredths  of  a  volt.  »/ 


voltage  =  adtoint( addata ,MULT_10V ) > 
if  (voltage  <  MIN_VOLTAGE_10 )  { 

returnlTRUE )> 
) 
retum(  FALSE  )> 


char  we_ launched (void) 

char  por-tdata>  /»  Holds  the  port  data.  »/ 

/»  Check  to  see  if  the  barometric  pressure  switch  tripped.  »/ 
baro_switch( ) i 

poptdata  =  input(READCl )> 

if  l(VIB_ON  I  BARO.ON)  8  portdata  )  { 

printf( "Launch  detected.   Turning  matched  filter  off.  n  r"  )  i 

lo9event(0LAUNCH ) ; 

logevent(power_write(MATFOFF  )  ?  CSOFFMATF  :  CFOFFMATF)> 

return  ( OLAUNCH  )  > 
) 

retum(  FALSE  )i 
) 

Q.     FILENAME  FPLTC.C 

/•    fputc.c    •/ 

"include  "inout.h" 

=include  "vibro.h" 

tJinclude  "expnnt.h" 

"include  "newio.h" 

int  fputc( int  chr,  void  *device)> 

/»  Bit  0  of  the  serial  port  is  TRUE  if  the  serial  port  is  ready  to  write 
a  character)  FALSE  otherwise. 

Bit  1  of  the  serial  port  is  TRUE  if  the  serial  port  is  ready  to  read 
a  character)  FALSE  otherwise.  »/ 
stnjct  rs252c  { 

L^signed  int  :6> 
Lnsigned  int  read_ready : 1 j 
unsi^ied  int  write_ready : 1 > 
}> 

/«  Implementation  of  fputc(  )  as  described  in  the  Uniware  Compiler  manual. 
For  the  NSC800  controller,  there  is  only  one  valid  output  device,  namely 
the  RS232C  terminal.   The  variable  "device"  is  therefore  ignored. 
This  module  must  be  place  in  Lnilib  libc.a  using  the  uar.exe  utility.  »/ 

int  fputcf int  chr,  void  »device) 


199 


struct  rs232c  portdataj 
char  port_status> 

/«  Allow  tl->e  user  to  interrupt  the  display  o-f  data  by  use  of  control 

characters.  »/ 
allow_ctrl_interrupts( )v 

/*   The  UNIWARE  manual  specifies  that  this  function  must  return  -1 

if  it  cannot  output  a  character.   If  there  is  no  terminal  attached* 
this  is  the  case.  »/ 
if  ( !checKprt( )) 

return! -1 ) \ 
do  C 

/*   Keep  getting  the  status  information  for  the  RS232C  data  port 

until  it  is  ready  to  accept  data.  «/ 
port_status=input( PRTCTRL ) \ 
portdata  =  *( struct  rs232c  »)  &port_statusj 
)  while  ( !portdata.write_ready  )  > 

/*  Otherwise}  output  the  character  and  return  it.  */ 
output! PRTDATA, (char)  chr  )  v 
return! chr  )  \ 


R.     FILENAME  GLOBAL.H 

/*  This  file  contains  external  prototyping  declarations  of  data  used  globally 
throughout  the  control  program.  »/ 

:ern  char  pr tconnectedj 

ern  char  tempbuf f er [ PAGELENGTH  ]  > 

ern  struct  datetime  clocks 

ern  struct  idatetime  waketinev 

ern  struct  power_port_fmt  power_port> 

ern  char  adportL ADPOINTS  ]  > 

ern  char  pageO_buf  f-^rLPAGELErJCTH  ]  i 

char  log_bu-ffer[PAGELENGTH]i 

struct  pageOdata  *pagezero> 

struct  full_log_page  *log_page> 

char  »adcaption[ ] > 


S.     FILENAME  GLOBAL.C 

/»   global. c    »/ 

/«   This  file  contains  the  declarations  of  global  variables  needed  by 
the  control  program.  »/ 

ttinclude  "vibro.h" 

char  prtcomected)  /»  TRUE  if  there  is  a  terminal  attached)  FALSE 

otherwise.  «/ 

char  tempbufferE PAGE LENGTH!)  /»  A  temporary  buffer.  »/ 

struct  datetime  clock>  /*  The  most  recently  read  time  will  be 


stored  here.  */ 

struct  idatetime  waketime>        /»  The  most  recently  read  integer  version  of 
time  will  be  stored  here.  */ 

struct  power_port_fmt  power_port> 

/*  This  is  a  list  of  A/D  channels  in  use>  and  what  they're  used  for. 

Make  sure  ADPOINTS  =  the  ntjnber  of  transducers  in  use.  «/ 
char  adportlADPOim-S]  =  { 

VOLTO,  VOLTl,  V0LT2, 

TEMPO,  TEMPI,  TEMP2,  TEMP3,  TEMP<»,  TEMPS,  TEMP6 
)> 

char  pageO_bufferIPAGELENGTH]>     /»  A  buffer  for  bubble  memory  page  0.  »/ 
char  log_bufferlPAGELENGTH]i  /»  A  buffer  for  bubble  memory  log  data.  »/ 

struct  pageOdata  »pagezero)       /»  A  pointer  to  the  pageO_buf fer.  »/ 
struct  full_log_page  *log_page>    /*  A  pointer  to  the  log_buffer.  */ 

/»  The  following  captions  should  match  the  A/D  port  assignments, 

in  order.  See  the  vibro.h  header  file.*/ 
char  ♦adcaption[ ]  =  { 

•'♦20V  Bus", 

••-20V  Bus", 

"♦lOV  Bus", 

"T,  shelf  above  BMC", 

"T ,  underside  of  speaker", 

"T ,  shelf  above  batteries", 

"T,  batteries", 

"T  ,  controller  backplane", 

"T,  card  8  of  BMC", 

"T,  card  9  of  BMC" 


T.     FILENAME  INITIAL. H 

/•  This  file  contains  external  prototyping  decalarations  for  all  functions 
in  "initial. c".  »/ 

extern  void  ini thardwarel void ) > 

U.     FILENAME  INITIAL.C 

/»   initial. c  */ 

^include  "vibro.h" 
Sinclude  "inout.h" 
'include  "newio.h" 

void  inithardwaret void)) 


/»  This  routine  initializes  the  NSC810A  ports.  »/ 
void  inithardwarel void ) 


output(MDRl,OxOO)> 

outptjt(DDRAl,Oxff  )> 

ootput(DDRBl,Oxff )> 

o<jtput(DDRC  1,0x50)  J 
output(TM01,OxOO)> 
output (TMQl, 0x25 )) 


output(T0LBl,0x07)> 
output! TOHBl, 0x00 )i 


output! STARTOl ,0x00 ) I 
output! MDR2, 0x00 ) ; 

output! DDRA2, 0x00 )> 

output! DDRB2,0x00) I 

output! DDRC2, 0x21 )> 
output! TM02, 0x00 )> 
output (TM02, 0x25)) 


output! T0LB2, 0x01 )> 
output (T0HB2, 0x00 )> 


/*  A  0x00  in  the  Mode  Definition  Register 
of  NSC810  »1  puts  port  Al  into  basic  I/O 
mode.  «/ 

/»  Set  port  Al  to  output. 

Al  is  used  to  output  command  codes  to 
the  SSDR.  »/ 

/»  Set  port  Bl  to  output. 

Bl  is  used  to  send  command  codes  to  the 
power  subsystem.  */ 

/*   Set  port  CI  to  input/output. 
Bits  are  defined  in  vibro.h  «/ 

/*   Stop  timer  0  of  NSC810A  »1.  You  must  do  this 
before  changing  the  timer's  mode.  »/ 

/*   Set  timer  mode  to  generate  square  waves 
without  pre-scaling,  and  with  single- 
precision  selected,  meaning  only  the  low- 
order  byte  is  ever  read.  */ 

/*   Set  low-order  and  high-order  byte  for  timer.  »> 

/*  The  modulus  is  thus  7.   After  2»l 7  +  1 ) 

cycles,  the  timer  is  reloaded.   Since  the 
NSC800  clock  has  a  frequency  of  ^.9152  Mhz, 
and  this  is  divided  by  2,  the  timer  produces 
one  pulse  every  6.51  mus ,  for  a  155.6  KHz 
signal.   This  signal  is  fed  to  the  UART  where 
it  is  divided  by  16  to  give  a  9600  BAUD  clock 
for  serial  communications.  */ 

/*   Restart  timer  0  of  NSC810A  «1  by  writing 
anything  to  it.  */ 

/»  A  0x00  in  the  Mode  Definition  Register 
of  NSC810  »2  puts  port  A2  into  basic  I/O 

/*  Set  port  A2  to  input. 

A2  is  used  to  read  status  codes  from  the 
SSDR.  »/ 

/»  Set  port  B2  to  input. 

B2  is  used  to  read  relay  position  codes 
from  the  power  subsystem.  */ 

/*  Set  port  C2  to  input/output. 
Bits  are  defined  in  vibro.h*/ 

/*   Stop  timer  0  of  NSC810A  «2.  You  must  do  this 
before  changing  the  timer's  mode.  */ 

/*  Set  timer  mode  to  generate  square  waves 
without  pre-scaling,  and  with  single- 
precision  selected,  meaning  only  the  low- 
order  byte  is  ever  read.  «/ 

/*  Set  low-order  and  high-order  byte  for  timer.  »/ 

/»  The  modulus  is  thus  1  decimal.   After  2»l 1*1) 
cycles,  the  timer  is  reloaded.   Since  the 
NSC800  clock  has  a  frequency  of  '♦.9152  Mhz, 
and  this  is  divided  by  2»  the  timer  produces 
one  pulse  every  1.628  mus,  for  a  61<^.^  KHz 
signal.   This  signal  is  fed  to  the  A/D 
converters.   For  a  6^+0  KHz  clock,  the  A/Ds 


will  complete  a  conversion  in  about  100  mus . 

We  are  not  far  from  b'+O  KHz>  so  should  get 

comparable  performance.   */ 
ootputlSTART02,0x00  )>     /»  Restart  timer  0  of  NSC810A  82  by  writing 

anything  to  it.  */ 
output(&CLRC2,0x30  )>  /»  Ensure  that  power  is  not  applied  to  the 

bubble  memory  and  that  a  reset  is  applied  to 

it.   This  should  be  done  when  the  NSC810  firs' 

receives  power,  but  we  leave  nothing  for 

granted.  */ 


V.     FILEN.\.ME  INOLT.H 

/»  This  file  contains  external  prototyping  declarations  for  all  functions 
in  "incut. c".  ♦/ 

I  void  allow_ctrl_interrupts( void  )  J 

>  void  dunp( unsigned  int  address,  ij^signed  int  length)) 
)  char  gethexi void  )  V 
«  unsigned  int  gethexinti void  )  > 
1  in-t  getinti  void  1  > 

>  int  getpagcnoi void  I J 
1  char  look_aheadl char  »character)v 

>  char  look_ahead_discard( void  I V 
\   void  portdunpl char  ♦string  I  > 

>  char  termini  void  )  V 
»  void  testinputi void  )  I 
1  void  testoutputf void  )  I 


W.     FILENA.ME  I.NOLT.C 

/»      inout.c   »/ 

^include  "vibro.h" 
^include  "convert. h" 
^include  "newio.h" 
^include  "bubble. h" 
"include  "expmt.h" 
cinclude  "global. h" 
sinclude    "main.h" 

void   allow_ctrl_intern-pts( void )> 

void   dv^ipl  unsi^Ted    int   address,    unsi^->ed    int    length)) 

char  gethexi void ) » 

unsigned  int  gethexinti void ) > 

int  getinti void ); 

int  getpagenol void ) I 

char    looK_aheadi char    •character)) 

char    looK_ahead_discardi  void l> 

char    termini  void  ) ; 

void    testinputi void ) > 

void    testoutputi void )> 


/»  console_buffGr  is  shared  by  look_ahead(  )  and  termini  ).   If  look_ahead(  ) 
reads  a  character  in,  it  puts  it  in  the  buffer  and  sets  the 
console_data_available  flag  to  true. 
termin(  )  will  look  first  in  the  buffer  for 

input  from  the  console.   If  it  finds  any,  it  will  set  console_data  to  false 
and  return  the  character  in  the  buffer.   Otherwise  it  will  try  to  get  a 
character  from  the  console  in  iUe   usual  way.  »/ 

static  char  console_buf fer v 

static  char  console_data_available  =  FALSE ( 


/*   This  routine  processes  the  special  characters  CTRL  S  and  CTRL  Y  from 

the  keyboard.  */ 
void  allow_ctrl_interrupts( void) 

i 

char  concharj  /«  The  character  of  console  input  data  itself.  */ 

char  char_availablev  /*  TRUE  if  there  is  a  character  available  for 

input  from  the  consoles  FALSE  otherviise.  »/ 

/»  If  there  is  a  S  character  in  the  RS232C  input  port,  then  read  it 
in  using  termin(  )  and  loop  until  another  S  is  given.   Thus,  S 
serves  as  a  toggle  for  stopping  and  starting  output.  */ 

/*   See  if  there  is  a  character  available, 

and  if  so,  put  it  in  conchar.*/ 
char_available  =  look_ahead( Sconchar ) v 

if  ( char_available )  { 
switcht conchar )  { 
case  CTRLS: 
case  CTRLY: 

/»  Call  termini  )  to  empty  the  buffer  and  handle  the 

control  character.  */ 
termini  )j 
break  V 
default: 

break  \ 
) 
) 


/*  This  routine  produces  a  hexadecimal  dump  of  any  section  of  memory. 

void  dump( unsigned  int  address,  unsigned  int  length) 

< 

unsigned  int  i(  /»  Points  to  the  current  byte  being  c 

char  asciitOUMPWIDTH+ll}  /»  Contains  the  ASCII  equivalent  of  each  byte. 

asciilDUMPWIOTH]  =  NULL>  /«  Make  sure  ascii  has  a  null  delimiter 
to  look  like  a  C  string,  »/ 

/»  Convert  length  to  a  multiple  of  DUMPWIDTH.  »/ 

length  =  ((length  ♦  DUMPWIDTH-1 )/DUMPHIDTH  )  *  DUMPWIDTH v 

for  ( i=0»i<length>i  +  + )  { 

if  (0==iXDUMPWIOTH)  {     /»  Dump  the  ascii  version  and  start  a 

new  line  every  DUMPWIDTH  characters.  */ 
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if  (  i  >  0)  i 

printfl  "'/.s  n  r"  ,ascii  )i 

} 

/*   Also,  dump  the  current  address.  */ 

printfl "Xs:   " ,ui tohl address  +  i  )  )> 
) 

/»  Put  exira  spaces  in  the  middle  of  each  line.  »/ 
if  (0==iZIDUHPHIDTH/2)  «S  0  •=  iXDUMPWIDTH )  < 

printfC   ")v 
> 

printfC'Zs  " ,ctoh( »( char  »)  ( address  +  i  ) )  )  >     /»  Dump  each  byte  individually.  »/ 
/»  Insert  the  current  character  in  the  string  "ascii".*/ 
/«  If  it's  not  printable,  replace  it.  »/ 
asciitiXDUMPWIDTH]  =  »(char  »)  (address+i)> 
if  lasciiLiZDUMPWIDTH]  <  SPACE  ||  ascii[ iXOUMPHIDTH  ]  >=  DELETE)  { 

ascii[iXDUMPHIDTH]  =  '.•> 
) 

^  Make  sure  ascii  is  printed  again  at  the  end  of  the  last  line.  */ 
■  (  i  >  0)  { 

printfl "/s  n  r", ascii )i 


/*   This  routine  gets  a  hexadecimal  byte  from  the  terminal.*/ 


char  gethexlvoid) 


char  string[HSTRLEN  ♦  lb 

string[HSTRLEN]  =  NULL) 
for  I  i=0;  i  <  HSTRLEN-,+  +  i  )  { 

string[ i )  =  tolower( termin(  )  ) > 
if  (string[ i  ]  ==  BS  )  { 
i  -=  Zi 
if  I i  <  -1)  { 

i  =  -1) 
)  else  { 

printfl  "b  b")) 
) 

continue) 
) 

printf("Xc",stringri])j 
if  (stringli]  >=  'a'  SS  string[i] 

continue) 
if  (string[i]  >=  '0'  SS  string[ i  ] 

continue) 
stringti]  =  NULL) 
break) 
) 
return! atoh( string  )  )) 


/*   This  routine  gets  a  hexadecimal  word  (two  bytes  1  from  the  terminal. »/ 

signed  int  gethexintt void ) 

int  ij 

char  stringlHEXIhfrSTRLEN*l]> 

string[HEXINTSTRLEN]  =  NULLj 
for  (i=Ovi  <  HEXINTSTRLEN>  +  *i  )  C 
stringti]  =  tolower( termin( )) v 
if  (stringlil  ==  BS )  { 
i  -=  Z\ 
if  ( i  <  -1)  C 

i  =  -\s 
}  else  { 

printfC'b  b"  )  > 
} 

continuej 
) 

printf("Xc",string[i] )j 
if  (string[i]  >=  'a'  SS  stringti]  <=  'f) 

continue > 
if  (stringti]  >=  '0'  88  stringti]  <=  '9') 

continue! 
stringti]  =  NULLl 
break > 
} 
return(atohexint( string  )  )  \ 


/»  Get  an  integer  from  the  terminal.  */ 
int  getint(void) 

int  i  s 

char  stringtSTRLEN]> 

stringtSTRLEN]  =  NULLj 
for  (  i=0>i  <  STRLEN-,  +  +  i)  { 
stringti]  =  termin()) 
if  (stringti]  ==  BS)  C 
i  -=  2) 
if  ( i  <  -1)  { 

i  =  -\\ 
}  else  < 

printf ( "  b  b")) 
} 
continue) 


printf  (  "/^c"  ,stringt  i  ] )  j 

if  (stringlil  <  '0'  ||  stringti]  >  '9')  < 

stringti]  =  hAJLL) 

break) 


i(  atoif  string) 


int  getpagenol void  ) 
{ 

int  page> 

char  sESTRLEN]}       /*   Storage  for  itoa(  ).  */ 

itoalMAXPAGE,s)> 

printf  I  "Input  thie  bubble  memory  page  number  (  0-Xs  decimal):   ">s)) 

while  (TRUE)  C 

page  =  getint(  ) s 

printfC  n  r"  )  > 

if  (page  >=  0  SS  page  <=  MAXPAGE ) 
breaks 

itoa(MAXPAGE,s  )> 

printf ( "Page  must  be  in  the  range  ( O-Xs  decimal):   "»s)j 
} 
returnl page  )  s 


/»  This  function  checks  to  see  if  a  character  is  available  through  termin(  ). 
It  places  the  character,  if  any,  in  the  location  pointed  to  by 
'character'.   It  returns  TRUE  if  there  was  a  character,  FALSE  otherwise.  */ 

char  look_aheadl char  »character  ) 

/»  If  there  is  no  terminal  attached,  return  FALSE.  »/ 
if  I  rchecKprtl  )  I  < 

returnl FALSE  W 
} 
/*   If  the  buffer  is  already  full,  return  it's  contents, 

but  don't  empty  it.  »/ 
if  I  console_data_available  )  { 

^character  =  console_buf fer > 

return(TRUE  ^\ 
} 
/«  Check  the  RS252C  port  to  see  if  there  is  data  available. 

Bit  1  will  be  1  when  data  is  present.  »/ 
if  ( input(PRTCTRL  )  i  PRTRDY  )  { 

/»  If  there  is  data,  store  it  in  the  buffer  and  let  termin(  )  know 
about  it  by  setting  the  console_data_available  flag.  */ 

•character  =  console_buf fer  =  inputl PRTDATA  )  > 

return(console_data_available  =  TRUE ) > 


retum(  FALSE  )>  /»  h4o  data   was   present.    */ 


/»  This  routine  checks  to  see  if  a  character  has  been  entered  from  the 
keyboard.   If  so,  it  discards  the  character  and  returns  TRUE.   If  not, 
it  returns  FALSE.  »/ 

char  look_ahead_discard( void ) 

if  (look_ahead( (char  •)  NULL))  < 


termin(  )\ 
return! TRUE  )> 
)  else 

returnt FALSE  )> 


/*  This  -function  obtains  a  character  from  the  keyboard.  */ 

char  ierfflin(void) 

C 

static  char  allow_menu_call  =  TRUE j 

/*  'allow_menu_call '  is  true  if  menu(  )  can  be  called  from  termin(  ), 

FALSE  otherwise.  It  can  be  called  from  termin(  )  once>  subsequently, 
it  must  first  return  control  to  termini  ).  Thus*  one  recursive  entry 
into  menul  )  is  permitted  at  a  time.  The  experiment  can  be  monitored, 
but  only  at  one  subordinate  calling  level  and  no  more.  »/ 

char  waiting_for_ctls> 

/*  This  variable  is  true  if  an  odd  number  of  CTRL-S  characters  has 
been  accepted.   No  characters  can  be  accepted  from  the  keyboard 
until  an  even  number  of  them  have  been  received.   However,  CTRL-Y  can 
be  accepted,  in  which  case  menu(  )  will  be  called  at  once.  */ 

char  ctrl_valid_data>     /*   This  is  TRUE  if  look_ahead(  )  already  filled 
the  buffers  FALSE  otherwise.  »/ 

waiting_for_ctls  =  FALSE j 
ctrl_valid_data  =  console_data_available> 

/*  Loop  continuously  until  an  acceptable  character  has  been  received.  */ 
while  (TRUE  )  { 

/*  If  the  buffer  is  empty,  then  wait  for  a  character  to  be  entered. 

It  could  have  been  filled  by  look_ahead(  ).*/ 
if  ( !console_data_available )  i 
while  (TRUE)  { 

/»  Check  the  RS232C  port  to  see  if  there  is  data  available. 
Bit  1  will  be  1  when  data  is  present.  Wait  for  data.  */ 
if  ( input(PRTCTRL  )  8  PRTRDY  )  { 

console_buf fer  =  input! PRTDATA )> 
break > 


/»  Now  that  console  data  has  been  read>  set  the  availability  flag 
FALSE  so  that  if  it  becomes  necessary  to  read  another  character> 
you  can  do  so.  »/ 
console_data_avai labia  =  FALSE) 
switch  ( console_buf fer )  { 
case  (CTRLS): 

/»  Toggle  the  waiting_for_ctls  flag.   As  long  as  this  flag 

is  true,  you  can't  get  out  of  termin(  ).  »/ 
waiting_for_ctls  =  !waiting_for_ctls > 
if  ( ( !waiting_for_ctls  )  &8  ctrl_valid_data  ) 

return! console_buf f er  ) ) 
break > 
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case  (CTRLY): 

/»  You  can  execuie  a  CTRL-Y  even  if  a  CTRL-S  is  pending. 

The  effect  is  to  cancel  the  CTRL-S.  */ 
waiting_for_ctls  =  FALSE > 
if  ( allow_menu_call  )  { 

allow_menu_call  =  FALSE j 

/»  Tell  menu! )  not  to  start  the  experiment.   This  is 

only  permissible  when  main(  )  is  the  calling  function.  •/ 

menu( 'EXPERIMENTOK )> 

allow_menu_call  =  TRUE) 
) 
if  (ctpl_valid_data) 

return! console_buf f er  )  i 
break  > 
d«fault: 

/»  Ignore  this  character  if  you're  waiting  for  a  second  CTRL-S.  «/ 
if  lwaiting_for_ctls  )  { 

break} 
} 
returnl console_buf f er ) > 


/»  This  function  allows  the  user  to  read  data  from  any  port.  »/ 

void  testinputl void  ) 

{ 

int  port)         /»  Port  number  to  be  entered  from  the  keyboard.*/ 
char     dataj    /»  Data  to  be  read  from  that  port.  «/ 

printf I "Specify  port  address  to  be  read  (in  hexadecimal):  "); 

port  =  gethext  )\  /*   Get  the  port  address.  »/ 

printfi  ■•  n  r"  l> 

data  =  input! port);       /»  Read  from  the  port.  */ 

printf ( "Data  from  port  (in  hexadecimal):   Xs  n  r" ,ctoh( data  )  )  > 


/»   This  routine  outputs  a  character  to  a  specified  port.  »/ 

void  testoutput( void ) 

{ 

int  port)        /*  The  port  address.  »/ 

char  dataj       /»  The  data  to  be  sent  to  the  port.  «/ 

printf ( "Specify  pert  address  to  be  written  to  (in  hexadecimal): 

port  =  gethex( ))      /•  Get  the  port  address.  «/ 

printf ("  n  r")j 

printf ( "Specify  the  data  to  be  sent  to  the  port  (in  hexadecimal): 

data  =  gethex(  )  i 

output! port, data  J > 
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X.     FILENAME  MAIN.H 

/»  This  file  contains  external  prototyping  declarations  for  all  functions 
in  "main.c".  »/ 

extern  void  memo ry_dump( void) j 

extern  char  menu! char  experiment_f lag )  > 

extern  void  program! void  ) ) 

extern  void  testio( void  ) ) 

extern  void  main(void)j 


Y.     FILENAME  MAIN.C 

/»  main.c  */ 


nclude 

"vers  ion. h' 

nclude 

"vibro.h" 

nclude 

"bubble. h" 

nclude 

"inout.h" 

nclude 

"power. h" 

nclude 

"convert .h 

nclude 

"initial. h 

nclude 

"clock. h" 

nclude 

"newio.h" 

nclude 

"global. h" 

nclude 

"expmnt .h" 

void  mcmory_dumpl void )) 

char  menu ( char  exper iment_f lag  )  i 

void  testiot void  J > 

void  main( void) j 

/**»***»*')Ht»»»*»**«»»*»*****#*«*««*»«*«**  »**»*****»*«*»**»«#»*•■»*»»»■»»«#**/ 

/*  This  routine  lets  the  user  produce  memory  dumps  for  any  section  of  memory.*/ 

void  memory_dump( void ) 

{ 

unsigned  int  addressj     /*  Mill  hold  the  starting  address  of  the  dump.*/ 
unsigned  int  length)  /»  Will  hold  the  number  of  bytes  to  dump.*/ 
while  (TRUE)  i 

printf( "Please  specify  address:   ")> 

address  =  gethexinti )) 

printf  (  "  n  rPlease  specify  number  of  bytes  to  dump  (0  to  quit):   ")j 

length  =  gethexint( )) 

printf ( "  n  r"  )  J 

if (length  ==  0) 

break) 
dump( address  > length ) ) 
) 
) 

/WMWMIIMMMKWWKlOiHOHtWXWKMWKMUXXMXmOOCKWMKIIWXimXWKXiOOIWIOIMIIKKWMKIOKKKKKMICMMW/ 

/»  This  routine  is  the  highest  level  of  all  the  diagnostic  menus. 

It  will  not  permit  the  experiment  to  be  run  unless  the  experiment_f lag 

is  TRUE.  */ 
char  menuCchar  experiment_f lag  ) 


char 

dataj 

int 

i> 

chap 

addatav 

int 

valuer 

/»  A  character  read  from  the  keyboard.  */ 

/»  A  counter.  */ 

/*   A  value  read  from  the  A/D  converter.  */ 

/*   The  A/D  reading  converter  to  useful  units.  »/ 


while! TRUE)  i 

version!  )j 

printfC 
A   Soft>*are  reset,  n  r 
B   Realtime  clock  functions,  nr 
C   Power  relay  switching  functions.  nr\ 
D   Bubble  memory  test  functions,  nr 
E   A/D  converter  fL*>:tions.  n  r 
F   Run  experiment,  n  r 
G   Perform  port  I/O.  n  r 

H   Display  contents  of  controller  memory,  n  r 

I   Exanine  or  change  the  data  logged  in  the  bubble  memory,  n  r 
Z   Exit  this  menu,  n  r"  )( 


/»  Read  in  a  character  froi 

and  display  it.  */ 
data  =  tolower! termini ))j 
printfC'Xc  n  r",data)» 
switch  (data)  { 
case  'a': 


the  keyboard,  convert  it  to  lower  case. 


/*  To  perform  a  software  reset >  jump 
to  address  0.  */ 


rtcl  )i 

breaks 
case  'c' : 

pwrcnt!  )l 

break  V 
case  'd' : 

bubnenu(  ) \ 


/*   Call  the  real  time  clock  functions.  »/ 


/*  Call  the  power  control  functions. 


/»  Call  the  bubble  memory  testing 


breaks 
case  'e' : 


/»  Display  the  A/D  data 


for  (i  =  Oji  <  ADPOINrTS>+  +  i  )  { 

addata  =  ad_readl adport[ i ]  )  > 

pr  intf  (  "/-2<+s=/3  .  Od="  ,adcapt  ion[  i  1 , addata  )  \ 

/»   If  i  <=  2,  then  the  A/D  reading  is  a  voltage.  »/ 

if  ( i  <=  2)  C 

value  =  adtoint! addata, ( i==2)?MULT_10V  :  MULT_20V)> 
printfl "/c/2.0d./02.0dV   ",  I i  =  =  l)? '-':'♦•  , 
value/100  ,value;<100  )  i 


/*   Otherwise,  the  A/D  reading  is  a  temperature.  */ 
}  else  { 

value  =  adtoint{ addata, MULT_TEMP)> 
printf I "/6.0dK   ",value)> 


/»  Print  two  points  per  line.  »/ 
if((0!=iX2)l|i==  ADPOINTS  -  1) 
printfC*  n  r"  )i 

y 

break > 
case  'f  :  /*   Execute  the  experiments  unless  it 

is  currently  in  a  suspended  state.  */ 

if  lexperiment_f lag)  i 

expmnt(  )i 
}  else  { 

printf ( "You  cannot  run  the  experiment  functions  while  \ 
is  suspended  with  Y.  n  rExit  this  menu  and  try  again.  nr")j 
} 

break » 
case  'g':  /*  Enter  the  routine  which  reads  from  and 

writes  to  any  port.  */ 
testio(  )i 
break  J 
case  'h' : 

memory_dump(  )^  /*   Enter  the  routine  which  displays  the 

contents  of  selected  portions  of 
memory.  »/ 
break > 
case  '  i  '  : 

log_menu(  )\  /*   Enter  the  routine  which  permits  the 

contents  of  the  bubble  memory  log  to 
be  modified.  »/ 
break > 
case  '2* : 

return  I 
default: 

printf ("Use  a  valid  letter  please!  n  r"  )  i 


/»#')('W«««^'«««*#*«*«#*^«)(««4f  «««#«#*«««*'»«'»««»*«»'»(««'»  «'«»»^«««««««««#«*»«««««4(««a(/ 

/*  This  routine  allows  you  to  output  data  manually  to  any  port,  or  to  read 

data  from  any  port.  »/ 
void  testio(void) 
{. 

char     dataj    /*   A  character  entered  from  the  keyboard.  */ 

/*  Repetitively  display  the  following  menu  until  choice  Z  is  made.  »/ 

while  (TRUE)  { 
printf( 
"  nrManual  port  I/O  functions.   Pick  one!  n  r, 
A  Input,  n  r 
B  Output .  n  r 
Z  Return  to  previous  menu.  nr")> 

/»  Read  a  character  from  the  keyboard)  convert  it  to  lower  case* 

and  display  it.  »/ 
data  =  tolower( termin( ))) 
printf ("Xc  n  r",data)v 
switch(data)  { 


case  'a':  /»  Enter  the  function  which  allows  the 

user  to  read  data  from  a  port.  */ 

testinputi ) > 

break > 
case  'b':  /»  Enter  the  function  which  allows  the 

user  to  write  data  to  any  port.  «/ 

testoutputt  )( 

break > 
case  'z' :  /»  Quit.  »/ 

return  > 
default: 

printf("Use  a  valid  letter  please.  nr")i 

breaks 


/»  The  C  program  begins  here.   This  routine  gets  control  from  the  assembly 

language  program  which  resides  at  address  0.  »/ 
void  maim  void ) 
( 

/»  Make  sure  that  each  of  these  pointers  is  intialized  to  point  to  the 
sane  nenory  as  the  corresponding  buffer.   Thus  the  same  data  can  be 
accessed  either  as  a  list  of  characters  (a  buffer)  or  as  a  structure 
( if  the  contents  need  to  be  accessed  individually. )  */ 
pagezero  =  (struct  pageOdata  •)  pageO_buf fer i 
log_page   =  (struct  f ull_log_page  »)  log_bufferi 

/»  Initialize  the  system  ports.  »/ 
inithardware(  ) » 

/»  See  if  there  is  a  terminal  attached.   If  so,  turn  off  any  subsystems 

which  are  currently  on  and  enter  the  menu  diagnostic  system.  »/ 
if  I prtconnected  =  checkprt(  ))  { 
shut_down_no_log(  l> 
while  (TRUE  )  { 

menu(EXPERIMENTOK)i 
) 
/*  If  there  is  no  terminal  attached,  we  must  be  in  space,  so  run  the 

experiment.  */ 
}  else 

expmnti  )>    /»  Run  tl->«  experiment.  »/ 


Z.     FILENAME  .MBRK.S 

)   mbrk.s 

mbrki  )  fLTiction  for  use  with  malloc(  )  and  calloc(  ). 
File  "spec"  declares  a  single  section  of  RAM,  MRAMSZ  bytes  long, 
to  use  for  memory  allocation,  and  START  in  file  "start. asm" 
initializes  MBRKPTR  to  point  to  that  memory. 
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global   mbrk,MBRKPTR,MRAMSZ 

option   long=^  i    assume  long=^  bytes 


region 

code 

.:  push 

ix 

Id 

ix.O 

add 

ix.sp 

Id 

de,(MBRKPTR) 

Id 

a,d 

or 

e 

jr 

z,out 

Id 

a,(  ix+6) 

or 

(ix+7) 

Id 

bcO 

Id 

(MBRKPTR),bc 

Id 

1,( ix+8) 

Id 

h,( ix+9) 

Id 

(hi  ),lo  MRAMSZ 

inc 

hi 

Id 

(hi  )>hi  MRAMSZ 

inc 

hi 

Id 

(hl),0 

inc 

hi 

Id 

(hl),0 

jr 

ret 

out:  Id 

de,0 

ret:  Id 

sp,ix 

pop 

ix 

J  char  »mbrk(  long  size>  long  ^realsize  )j 


»  (  ix*'+,5,6,7):si2e,  (  ix+8,9  ) :  realsize 

i    return  value  is  address  of  memory  section 


i   zero   means  memory  section  is  in  use 


i    nonzero  means  more  than  64K  requested 
i    requested  'size'  to  be 

\    check  if  'size'  bytes  are  available 
i    assumes  MRAMSZ  is  less  than  6<+K 
J  clear  the  carry  flag. 


i    mark  memory  section  as  used 
\    de  still  holds  former  MBRKPTR 
i    get  the  pointer  to  'realsize' 

i    write  back  actual  size  of  memory  section 


\    de  is  the  return  value 

>  out  of  memory >  return  zero  pointer 


AA.     FILENAME  NEWIO.H 


extern  char  input(char  portU 

extern  void  output (char  port, char  data)> 


AB.     FILENAME  NEWIO.S 


export   input >  output 
region   code 

>  char  input(char  port)> 
input: 

push     ix  jThere  are  no  local  variables. 

Id       ix,0 


IX, sp 

c,(ix+<+)     >Put  port  address  in  register  c. 
a.lc)        >Get  the  data  from  the  port, 
ix  s Restore  ix  to  the  value  it  had  before  this 

^function  was  called. 


)  void  outpot  (char  port,  char  data)} 
output: 

push     ix 

Id       ix,0  (There  are  no  local  variables. 

add      ix,sp 

Id      c,(ix+4)  jPut  port  address  in  register  c. 

Id      a,(ix*6)  >Put  data  in  register  a. 

out      lc),a  (Write  the  data  to  the  port. 

pop      ix  (Restore  ix  to  the  value  it  had  before  this 
(function  was  called. 


AC.     FILENAME  POWER.H 

/»  This  file  contains  external  prototyping  declarations  for  all  functions 
in  "power. c".  */ 

extern  char  power_statusl void  )  ( 
extern  char  power_wr i te( char  command  J i 
extern  void  pwrcnt( void  )  ( 


AD.     FILENA.ME  PO\\  ER.C 

/*   power. c  */ 

«include  "vibro.h" 
^include  "bubble. h" 
"include  "convert. h" 
«include  "inout.h" 
^include  "delay. h" 
^include  "expmnt.h" 
^include  "newio.h" 
Itinclude  "global. h" 

char  power_status( void )( 

char  power_write( char  command ) ( 

void  pwrcnti void  )( 

/*  This  routine  gets  the  status  from  the  power  board.  »/ 

char  power_status( void  ) 

return! input  1 POWERIN ) ) ( 
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/*  This  routine  sends  commands  to  tlie  power  board.  */ 

char  power_write(char  command) 
i 

int  i^ 

char     status ( 

char     oncommandj   /»  TRUE  if  command  is  an  ON  command > 

FALSE  otherwise.  »/ 
char     relayon^     /»  TRUE  if  the  indicated  relay  is  on> 

FALSE  otherwise.  */ 
/*   Try  to  send  the  command  to  thte  power  board. 

Return  TRUE  if  successful.   Return  FALSE  after  you  give  up 
in  disgust.  */ 
fori i=0>i<TRIES>i+*)  { 

output! POHEROUT , command ) i 

output ( BSETCl ,PWRSTROBE  )  \ 

delay(PHRDELAY  )> 

output! BCLRCl .PWRSTROBE  )  V 

delay(PWRDELAY  )>  /*  Wait  PHRDELAY  x  10  ms  for  the 

relays  to  respond.  »/ 
/»  The  command  is  intended  to  turn  a  relay  on  only  if  the 

last  bit  is  set  (1).  */ 
onconmand  =  OtJBIT  S  command  > 
status  =  NOPOWER  |  power_s tatus(  )i 
/*   To  see  whether  the  indicated  relay  is  on> 
see  whether  only  the  status  bit  in  the 

relay's  assigned  bit  position  is  a  zero.   If  it  is>  then 
that  relay  is  on.  */ 
relayon  =   status  S  command j 
/»  If  the  relay's  position  matches  that  commanded>  then 

log  a  successful  setting  of  the  relay.  */ 
if  ( ( oncommand  SS  relayon)  ||  ( !oncommand  &S  !relayon))  { 

return(TRUE  )i 
) 
printf(  "Trying  again  to  switch  relays.  nr")> 


/*  If  you  got  this  far,  then  the  relay's  position  did  not  match 

that  commanded,  so  log  a  failure.  »/ 
return( FALSE )> 


/»  This  routine  sends  commands  to  the  power  board.  */ 

void  pwrcnt(void) 

char     dataj    /»  Data  from  the  keyt>oard,  »/ 

static  int  relay[ 1  =  { 

SSDRON,  SSDROFF,  VCOON,  VCOOFF,  ADON,  ADOFF, 
MATRON,  MATFOFF,  HEATON,  HEATOFF 

while(TRUE)  < 
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printfl  '•  n  rPOWER  SWITCH  CONTROL,  n  r  n  r, 
A  =  SSDR  on.  n  r 
B  =  SSDR  off .  n  r 
C  =  VCO  on.  n  r 
D  =  VCO   off .  n  r 
E  =  A/D  on.  n  p; 
F  =  A/D  off.  n  r 
G  =  MATCHED  FILTER  on.  n  r 
H  =  MATCHED  FILTER  off.  n  r, 
I  =  HEATER  on.  n  r 
J  =  HEATER  off.  n  r 
K  =  READ  power  status  port,  nr 
Z  =  Back  to  the  MAIN  MENU,  n  r"  ) ) 

data  =  tolower( termin(  ))j 

printft "Xc  n  r",data  )> 

if  (data  >=  'a'  8S  data  <=  'j')  { 

if ( ?power_write( relay [data- 'a ' ] ) ) 

printfl "Power  control  command  failed.  nr")> 
}  else  { 

switch  ( data  I  { 
case  'k' : 

printf ( "Xs  n  r" ,ctoh( power_status(  ) ) )> 
break) 
case  ' z'  : 

returnj 
default: 

printf  (  "Use  a  valid  letter,  please.  nr")> 
break i 


AE.     FILENA.MESTART.S 


February  19,  1988  start. s 

This  startup  code  initializes  interrupt  vectors  and  rvns  START  at 

reset 

to  initialize  RAM  and  call  the  user  function  main(  ). 

The  companion  link  specification  file  is  "spec"  which  defines 

many  of  the  imported  syrtijols.   Also  see  file  "mbrk.asm"  for  the 

mbrk(  )  function  if  you  want  to  use  mallocC  )  or  calloci  ). 

The  program  is  adapted  frotn  an  example  given  in  the  UNIMARE 

manual,  Compiler   section,  pp.    13-15. 

export   START, MBRKPTR 

import   main,STACKT0P,RAMDATA,ZRAM,ZRAMSZ,IRAM,IRAMS2,MRAM 


i         De-fine  a  variable  to  track  memory  allocations  in  mbrki  ). 
i    (char  *)  to  available  memory 


Reset  code  must  be  linked  to  address  0. 

region   reset 

Id   sp,  10  STACKTOP   >  initial  stack  pointer  (0x10000  as  0) 


jp   START 
org  0x08 


jp   START 
org  0x10 


jp   START 
org  0x18 


jp   START 
org  0x20 


jp   START 
org  0x28 


jp   START 
org  Ox2C 


jp   START 
org  0x30 


jp   START 
org  OxS't 


jp   START 
org  0x28 


jp   START 
org  0x5C 


jp   START 
org  0x66 


i    initial  execution  address 


jRESTART  LOCATION  1 


jRESTART  LOCATION  2 


^RESTART  LOCATION  5 


jRESTART  LOCATION  < 


jRESTART  LOCATION  5 


JRESTART  LOCATION  C 


> RESTART  LOCATION  6 


VRESTART  LOCATION  B 


^RESTART  LOCATION  7 


JRESTART  LOCATION  A 


jNON-MASKABLE  INTERRUPT 


This  code  can  be  anywhere >  the  reset  code  jumps  to  it. 


region  code 

START:  Id  ix,0 

Id  hl,MRAM 

Id  (MBRKPTR),hl 


)  end  of  stack  frame  chain 
)  initialize  memory  allocator 


Zero  out  uninitialized  RAM. 


}  It  is  assumed  here  that  ZRAMS2  >  1  but  this  is  guaranteed 

i    as  long  as  MBRKPTR  (above)  is  defined  in  region  ram. 

Id       hl,ZRAM  i    zero   ZRAMS2  bytes  here 

Id       (hl),0  i    zero  first  byte 

Id      de,ZRAM+l        >  repeatedly  zero  other  bytes 

Id       bc,ZRAMSZ-l 

Idir 


Initialize  other  RAM  from  ROM. 

hl,RAMDATA 
de,IRAM 
bcIRAMSZ 
a,b 


(  )  with  no  arguments 


call     nain  ;    any  return  value  is  " 

done:  halt  >  halt  if  main  returns 


To  vector  an  interrupt  to  a  C  function,  you  must  go  though 
a  register  save  routine  like  the  one  shown  here. 
If  the  "-r  exx"  option  is  being  given  to  the  command  line, 
then  registers  be'  de '  and  hi'  need  not  be  saved  and  restored 
since  the  compiler  will  make  no  use  of  them.   The  compiler 
does  not  use  af  in  any  case. 


region  code 
ilNTERRUPT 

>  push  af  i    save  registers 
)  push  be 

i  push  de 

)  push  hi 

)  push  ix 

)  push  iy 

)  exx 

>  push  be 
)  push  de 
)  push  hi 
)  exx 

)  call  cfcn  )  call  some  C  function 

>  exx 

)  pop  hi  )  restore  registers 

J  pop  de 

)  pop  be 

\  exx 

J  pop  iy 

)  pop  ix 

J  pop  hi 


pop 
pop 
pop 


)  return  from  interrupt 


AF.     FILENAME  ASM.BAT 

arem    Make  asmsource  the  current  subdirectory 

cd  vibro  contrlr  asmsource 

Srem    Assemble  the  specified  source  file 

uaszSO  -c  80  -n  -t  <♦  -L  /.I 

arem    Place  the  object  module  in  the  object  subdirectory 

copy  ».o  vibro  contrlr  object 

erase  ».o 

arem    Place  the  assembly  listing  in  the  list  subdirectory. 

copy  *.lst  vibro  contrlr  list 

erase  *.lst 


AG.  FILENAME  AS.MLIST.BAT 

arem  Fill  in  the  symbols  of  the  specified  assembly  listing  file 

arem  with  the  values  given  in  the  executable  module  u.out. 

arem  Pipe  the  completed  listing  to  the  ulist  program  to  give  a 

arem  decent  looking  print-out. 

uabs  vibro  contrlr  u.out  <  vibro  contrlr  lis t  XI  |  ulist  >>  temp  prii 


AH.     FILENAME  C.BAT 

arem    Make  csource  the  current  subdirectory. 

cd  vibro  contrlr  csource 

arem    Compile  the  source  file. 

ucczSO  -e  -1  -A  -L  --  '/.l 

arem    Place  the  resultant  object  module  in  the  object  subdirectory. 

copy  *.o  vibro  contrlr  object 

erase  *.o 

arem    Place  the  resultant  assembly  listing  in  the  list  subdirectory. 

copy  ».  1st  vibro  contrlr  list 

erase  *.lst 


AI.     FILENAME  LINK.BAT 

3rein    MaKe  object  -the  current  subdirectory. 

cd  vibro  contrlr  object 

Sretn    Link  the  specified  object  modules  together. 

ul«  -f  spec  -t  -V  XI  y.Z   /.I   /A   y.B  y.b   /.7  /.&  7.9 

Srem    Place  the  linked  mocKjle  in  the  contrlr  subdirectory  as  u.out. 

copy  •.out  vibro  contrlr 

erase  •.out 

arem    Create  an  executable  module  in  the  contrlr  subdirectory  as  u.bin. 

cd  vibro  contrlr 

ufihex  u.out  >  vibro. hex 


AJ.  FILENAME  LIST.BAT 

aren  Produce  a  paginated  listing  of  the  specified  file,  and 

arem  put  it  in  a  tenporary,  scratch  file  called  temp  print, 

ulist  -d  -t  <*    -X    -0  hdr=Xl  7.1    »     tenp  print 


AK.  FILENAME  LOAD.MAP.B.AT 

aren    Create  a  load  map  of  all  the  regions  in  i. 
unm  -m  vibro  contrlr  u .  out  >  tenp  tenp 
arem    Produce  a  paginated  print-out  of  it. 
ulist  -d  -0  hdr  =  loadrTap  tenp  tenp  >>  tenp  print 


AL.     FILENAME  PRINTALL.BAT 

aren     Produce  a  conplete  listing  of  the  load  map»  synbol  table  and 

arem    all  source  files,  and  header  files. 

cd  vibro  contrlr 

call  ready out 

call  loadnap 

call  pronsyn 

call  o 

call  list  spec 

call  h 

call  list  version. h 

call  cs 

call  list  version. c 

call  h 

call  list  vibro. h 

call  list  b^jbble.h 

call  cs 

call  list  bubble. c 

call  h 

call   list   bubrw.h 

call   s 

call   list  bubrM.s 

call  h 

call  list  clock. h 


call  cs 

call  lisl 

clock. c 

call  h 

call  lisl 

convert.h 

call  cs 

call  lisl 

convert. c 

call  h 

call  lisl 

delay. h 

call  s 

call  lisl 

delay. s 

call  h 

call  lisi 

expmnt.h 

call  cs 

call  list 

expmnt .c 

call  h 

call  list 

global. h 

call  cs 

call  list 

global. c 

call  h 

call  list 

initial. h 

call  cs 

call  list 

initial. c 

call  h 

call  list 

inout .h 

call  cs 

call  list 

inout.c 

call  h 

call  list 

main.h 

call  cs 

call  list 

main.c 

call  s 

call  list 

mbrk.s 

call  h 

call  list 

newio.h 

call  s 

call  list 

newio.s 

call  h 

call  list 

power. h 

call  cs 

call  list 

power. c 

call  list 

s.bat 

call  list 

start. s 

call  b 

call  list 

asm. bat 

call  list 

asmlist.bat 

call  list 

b.bat 

call  list 

backupl.bat 

call  list 

backup2.bat 

call  list 

c.bat 

call  list 

cs.bat 

call  list 

link. bat 

call  list 

list. bat 

call  list 

loadmap.bat 

call  list 

o.bat 

call  list 

printall.bat 

call  list 

protnlib.bat 

call  list 

protnlink.bat 

call    list   profnsym.bat 
call    list    readyout.bat 


AM.     FILENAME  PROMLINK.BAT 


cd  vibro  contrlr  object 
link  -F  linkfile  libc.a 


AN.     FILENAME  PROMOUT.BAT 

Srem    Put  the  print  scratch  file  into  the  printer  queue. 

copy  vibro  contrlr  batch  lpfont+  temp  print*  vibro  contrlr  batch  normfont  temp  print2 

print  temp  print2 


AO.     FILENAME  PROMSVM.BAT 

3rem    Put  the  symbols  from  u.out  into  a  scratch  file. 

tnn    -fnrstvttgx     vibro  contrlr  u.out      >     temp  tenp 

3rem    Produce  a  paginated  version  of  the  symbol  table  listing. 

ulist  -d  -0  hdr  =  synbols  temp  temp  >>  temp  print 


AP.  FILENAME  READVOLT.BAT 

3rem    Get  rid  of  the  two  scratch  files  used  in  producing  listings, 

erase  tenp  temp 

erase  temp  print 

erase  temp  print2 
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APPENDIX  I.     RS-232C  INTERFACE  PIN  CONNECTIONS 

This  appendix  contains  the  complete  electrical  specification  for  the  RS-232C  Inter- 
face. It  is  provided  here  for  convenience.  Only  a  subset  of  this  specification  has  been 
implemented  in  the  Vibro-acoustic  Experiment  for  the  purpose  of  providing  communi- 
cations between  the  controller  and  the  terminal,  which  is  useful  during  ground  testing. 


Table  16.     RS-232C  INTERFACE  PIN  CONNECTIONS 


Fin 

Number 

Circuit 
Desig- 
nation 

Mne- 
monic 
Desig- 
nation 

Direction 

Description 

1 

AA 

FG 

FR,-\ME  GROLND.    This  lead  is 
an  electircal  equipment  frame  and 
power  ground. 

2 

BA 

TD 

To  DCF 

TR^ANSMITTED  DATA.    This 
lead  carries  the  serial  digital  data 
transmitted  from  the  DTE  to  the 
DCE. 

3 

BB 

RD 

To  DIE 

RECEIVED  DATA.   This  lead 
carries  the  serial  digital  data  re- 
cei\ed  at  the  DTE. 

4 

CA 

RTS 

To  DCE 

REQLEST  TO  SEND.   An  "ON" 

condition  on  this  lead  is  used  to 
enable  the  local  DCE  for  data  tran- 
smi^Mon. 

5 

CB 

CIS 

To  DTE 

CLEAR  TO  SEND.   An  "ON" 

condition  on  this  lead  indicates 
whether  or  not  the  DCE  is  ready  to 
transmit  data. 

6 

CC 

DSR 

To  DTE 

DATA  SET  READY.   An  "ON"' 

condition  on  this  lead  indicates  that 
the  local  DCE  is  ready  to  process 
data  and  is  not  in  a  test,  talk,  or  dial 
mode. 

Source:  Couch,  L.  W.,  Digital  and  Analog  Communicaiion  Systems.  Macmillan  Pub- 
Ushing  Company,  1987,  pp.  684-686 


Table   17.     RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINITD) 


Pin 

Number 

Circuit 
Desig- 
nation 

Mne- 
monic 
Desig- 
nation 

Direction 

Description 

AB 

SG 

SIGNAL  GROUND.   This  lead  es- 
tablishes the  common  ground  refer- 
ence potential  for  all  circuits  except 
frame  ground  on  pin  1. 

S 

CF 

DCD 

To  DTE 

DATA  CARRIER  DETECT  (Re- 
ceived Line  Signal  Detector).    This 
lead  indicates  that  data  from  the 
remote  location  is  being  received 
and  meets  a  suitable  criterion  es- 
tablished by  the  DCE  manuiac- 
lurer. 

^ 

To  DIE 

Positive  DC  lesi:  \'oltage 

1" 

To  DIE 

Nceati\e  DC  Te^t  \'okaec 

11 

Boll 

type  cir- 
cuit 

QM 

To  DTE 

EQLALIZER  MODE.    This  lead  is 
used  to  indicate  to  the  DTE  that  the 
adaptive  equalizer  in  the  receiver  is 
reset  automatically  when  error  per- 
formance is  poor.  (non-EIA  desig- 
nated). 

i: 

SCF 

iSiDCE 

To  DTE 

SECONDARY  DATA  CARRIER 
DE7  ECT.    This  lead  i^  equivalent 
to  DCD  on  pin  8  e.xcept  that  it  in- 
dicates the  proper  reception  of  the 
secondary  channel  line  signal  in- 
stead of  the  primar\-  channel  re- 
cened  line  «^ignal. 

13 

SCB 

(S)CTS 

To  DTE 

SECONDARY  CLEAR  TO  SEND. 

This  lead  is  equivalent  to  CTS  on 
pin  5  except  that  it  indicates  the 
availability  of  the  secondary  chan- 
nel instead  of  indicating  the  avail- 
ability of  the  primary  channel  to 
transmit  data. 

Source:  Couch.  L.  W.,  Digital  and  Analog  Communicaiion  Systems.  Macmillan  Pub- 
lishmg  Company,  1987,  pp.  684-686 
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Table  18.     RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINL'ED) 


Pin 
Number 

Circuit 
Desig- 
nation 

Mne- 
monic 
Desig- 
nation 

Direction 

Description 

14 

SBA 

(S)TD 

To  DCE 

SECONDARY  TR.ANSMITTED 
DATA.   This  lead  is  equivalent  to 
TD  on  pin  2  except  thai  it  is  used 
to  transmit  data  via  the  secondary 
channel. 

Bell 

20SA 
type  cir- 
cuit 

NS 

To  DCE 

NEW  SYNC.   This  lead  may  be 
used  on  an  optional  basis  with  the 
DCE  at  a  master  station  of  a  mul- 
tistation private  line  network,  such 
as  in  a  polling  operation,  to  ensure 
rapid  resynchronization  of  the  re- 
ceiver on  data  from  many  difierent 
remote  transmitters  (non-EIA  des- 
ignated). 

15 

DB 

TC 

To  DIE 

TRANSM TITER  CLOCK.    This 
lead  is  used  to  provide  the  DTE 
with  signal  element  timing  informa- 
tion. 

16 

SBB 

iSiRD 

To  DIE 

SECONDARY  RECEIVED 
DATA.    This  lead  is  equivalent  to 
RD  on  pin  3  except  that  it  is  used 
to  recei\e  data  on  the  secondary 
channel. 

Bell 
2()SA 
type  cir- 
cuit 

DCT 

To  DTE 

DIVIDED  CLOCK.  TR.ANSMIT- 

TER.    A  square-wave  signal  at 
one-third  the  nominal  bit  rate  ap- 
pears on  this  lead  whenever  power 
is  supplied  to  the  DCE  (non-EIA 
designated.). 

Source:  Couch,  L.  W.,  Digiial  and  Analog  Communication  Systems,  Macrmllan  Pub- 
lishing Company,  1987,  pp.  684-686 


Table   19.     RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINUED) 


Pin 
Number 

Circuit 
Desig- 
nation 

Mne- 
monic 
Desig- 
nation 

Direction 

Description 

17 

DD 

RC 

To  DTE 

RECEIVER  CLOCK.   This  lead  is 
used  to  provide  the  DTE  with  re- 
ceived signal  element  timing  infor- 
mation. 

18 

Bell 

:OSA 

type  cir- 

'  cuit 

DCR 

To  DTE 

DIVIDED  CLOCK,  RECEIVER. 

A  square-wave  signal  on  this  lead 
provides  the  recei\er  timing  infor- 
mation at  one-tliird  the  nominal  bit 
rate  (non-EI.A  designate  J). 

19 

SCA 

(S)RTS 

To  DCE 

SECONDARY  REQUEST  TO 
SEND.    This  lead  is  equivalent  to 
RTS  on  pin  4  except  that  it  requests 
to  use  the  secondary  channel  in- 
stead of  the  pnmarv  data  channel. 

2'.> 

CD 

DTR 

ToDCE 

DATA  TERMINAL  RLADY.    An 
"ON"  condition  on  this  lead  indi- 
cates that  the  DTE  is  ready  to  be 
connected  to  the  communication 

chann.el. 

21 

CG 

SQ 

To  DTE 

SIGNAL  QUALITY  DLTLCT. 

This  lead  is  used  to  indicate  whether 
or  not  there  is  a  high  probability  oi' 
an  error  in  the  received  data. 

Source:  Couch.  L.  W..  Digital  and  A/. 
lishing  Company,  1987.  pp.  684-686 


alog  Coniniunicaiton  Systems.  Macniillan  Pub 


227 


Table  20.     RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINUED) 


Pin 
Number 

Circuit 
Desig- 
nation 

Mne- 
monic 
Desig- 
nation 

Direction 

Description 

22 

CE 

RI 

To  DTE 

RING  INDICATOR.   An  "ON" 

condition  on  this  lead  indicates  that 
a  ringing  signal  is  being  received  on 
the  communication  channel. 

23 

CH 

To  DCE 

DATA  R.ATE  SELECTOR.    This 
lead  is  used  to  select  between  the 
two  data  signalling  rates  in  the  case 
of  dual  rate  DCE. 

CI 

To  DTE 

DATA  IC-\TE  SELECTOR.   This 
lead  is  used  to  select  between  the 
two  data  signalling  rates  in  the  case 
of  dual  rate  DCE. 

24 

DA 

TC 

1  0  DCE 

EXTERNAL  TICANSMITTER 
CLOCK.    This  lead  is  used  lo  pro- 
vide the  transmitting  signal  con- 
verter with  signal  element  timing 
information. 

" 

Bell 
20SA 
t\  pe  cir- 
cuit 

To  DCE 

BUSY.    This  lead  is  used  for  testing 
purposes  by  Telephone  Company 
personnel  <non-ElA  designated). 

Source:  Couch.  L.  W.,  DigUal  and 
lishing  Company.  1987,  pp.  684-6S6 


inalog  Conununlcaiion  Systems,  Macmillan  Pub- 


228 


LIST  OF  REFERENCES 

1.  INTEL  Corporation,  BPK  5V75A  Four-Megabit  Bubble  Memory  Proioiyping  Kit 
User's  Manual,  No.  2444-001,  (undated). 

2.  Couch.  Leon  W.,  Digital  and  Analog  Communication  Systems,  Macmillan  Publishing 
Company,  19S7. 

3.  ^^'allin.  J.  W.,  Microprocessor  Controller  with  Xonvolatile  Memory  Implementation, 
MSEE  The^ls.  >'aval  Postgraduate  School.  Monterey,  CA.  December  1985. 

4.  •  GAS  Small  Self-contained  Payloads.  Experimenter  Handbook.  National  Aeronau- 
tics and  Space  .Administration,  Goddard  Space  Flight  Center.  I9S7. 

5.  Stehle.  C.  D..  Vibration  Isolation  of  a  Microphone,  MS  m  Engineering  Acoustics 
Thesis.  Naval  Postgraduate  School,  Monterey.  CA.  September  1985. 

6.  Jordan.  D.  \\'.,  A  Matched  Filter  Algorithm  for  Acoustic  Signal  Detection,  MSEE 
Thesis.  Naval  Postgraduate  School.  Monterey,  CA,  June  1985. 

7.  Boyd.  A.  \V..  Kosinski.  B.  P..  and  Weston.  R.  L.,  ".Autonomous  Measurement  of 
Space  Shuttle  Payload  Bay  Acoustics  During  Launch,"  Xaval  Research  Reviews, 
Vol.  39.  No.  1.  pp.  9-17.  1987. 

8.  Frey,  T.  J.,  Jr..  A  32-Bit  Microprocessor  Based  Solid  State  Data  Recorder  for  Space 
Based  Applications,  .MSEE  Thesis,  Naval  Postgraduate  School,  Monterey,  CA, 
March  1986. 

9.  Kuebler,  D.  P.,  Signal  Acquisition  and  Processing  for  Autonomous  Space  Shuttle 
Cargo  Bay  Acoustic  Measurements,  Defense  Technical  Information  Center  (DTIC) 
Report  No.  ADA200426,  Master's  Thesis,  Naval  Postgraduate  School,  Monterey, 
CA,  June  1988. 


10.  National   Semiconductor  Corp.,   XSCSOO  High- Performance  Low-Power  Micro- 
processor, July  19S3. 

11.  National  Semiconductor  Corp.,  SSC810A  RAM-lO-Timer,  Februar\-  1984. 

12.  Ghausi,  M.  S.,  and  Laker,  K.  R.,  Modern  Filler  Design,  Prentice-Hall,  Inc.,  1981. 

13.  Micro-Cap  III  Elecironic  Circuit  Analysis  Program  Insiruction  Manual,  First  Edi- 
tion, Spectrum  Software,  1988. 

14.  Jung.  W.  G.,  IC  Op-Amp  Cookbook,  Third  Edition,  pp.  236-237.  Howard  W.  Sams 
&  Company.  19S6. 

15.  S.   Michael,  Soies  for  EC4100  'Advanced  Xcr.vork   Theory/.  Naval  Postgraduate 
School.  Monterey.  CA,  1988  (unpubhshed). 

16.  Kernighan.  B.  W.  and  Ritchie.  D.  M..  The  C  Programming  Language,  Prentice-Hall, 
Inc.,  1978. 

17.  Software  Development  Systems,  Inc..  IWIU'ARE  Sofiware  Development  System. 
Release  3.2.  1986. 

18.  Bilofsky,  W.,  TOOLWORKS  CSO.  Version  3.1,  The  Software  Toolworks,  1984. 

19.  National  Semiconductor  Corp.,  Linear  Databook,  1982. 

20.  PCPP  PC  Personal  Programmer  User's  Guide,  Revision-002,  Change  1,  Intel  Cor- 
poration, 1987. 


INITIAL  DISTRIBUTION  LIST 

No.   Copies 

1.  Defense  Technical  Information  Center  2 
Cameron  Station 

Alexandna.  VA   22304-6145 

2.  Librar\-,  Code  0142  2 

Naval  Postgraduate  School 
Monterey,  CA   93943-5002 

3.  Comniander  1 
Naval  Space  Command 

Attn:   Code  N3 
Dahlgren.  VA   2244S 

4.  Commander  1 
United  States  Space  Command 

Attn:   Technical  Librarv 
Peterson  AFB.  CO   S0914 

5.  Na\A-  Space  Svstem  Division  1 
Chief  of  Naval  Operations  (OP-943) 

Washmgion.  DC   20305-2000 

6.  Department  Chairman.  Code  62  1 
Dept.  of  Electrical  and  Computer  Engineering 

Naval  Postgraduate  School 
Monterey.  CA  93943-5000 

7.  Dr.  Rudolf  Panholzer  2 
Chairman,  Space  Svstems  Academic  Group 

Code  72 

Naval  Postgraduate  School 

.Monterey.  CA   93943 

8.  Mr.  Larr}  Frazier  1 
Naval  Postgraduate  School 

Monterey  CA  93943-5000 

9.  Dr.  Sherif  Michael  1 
Dept.  of  Electrical  and  Computer  Eneineering 

Code  62Mi 

Naval  Postgraduate  School, 

Monterey,  CA  93943 


231 


10.  National  Aeronautics  and  Space  Administration 
Technical  Libran.- 

NASA  Headquarters 
600  Independence  Ave. 
Washington,  DC   20546 

11.  Mr.  David  Rigmaiden,  Code  72 
Space  Systems  Academic  Group 
Naval  Posieraduate  School 
Monterey,  CA  93943-5000 

12.  LT  Charles  B.  Cameron,  USN 
1139  LeahvRd. 
Monterey,  C A  93940-5318 

13.  Prof.  Steven  Garrett,  Code  61Gx 
Dept.  of  Physics 

Naval  Postgraduate  School 
Monterey.  CA  93943-5000 

14.  Prof.  Tom  Honer,  Code  61  Hf 
Dept.  of  Physcis 

Naval  Postgraduate  School 
Monterey,  CA  93943-5000 

15.  Space  Projects  Group.  Code  72 
Naval  Postgraduate  School 
Monterey.  CA  93943-5000 

16.  CDR  Steven  P.  Hannifm  USN 

c  0  Carrier  Airborne  Earlv  W'arnmg  Squadron  1 10 
NAS  Miramar,  CA  92145-5000 

17.  CDR  R.  Braden.  USN 

c  o  Carrier  Airborne  Earlv  Warnins  Squadron  110 
NAS  Miramar,  CA  92145-5000 

18.  CPT  R.  Byrnes,  USA 
CO  Code  39 

Naval  Postgraduate  School 
Monterey.  CA  93943-5000 

19.  Research  Administration  (Code  012) 
Naval  Postgraduate  School 
Monterey,  CA  93943 

20.  LT  Stewart  Cobb 
SSD  CLFPD 

P.  O.  Box  92960 
LLAFB 

Los  Angeles,  CA  90009-2960 


:  I .     OlTice  of  Naval  Research 

Phvsics  Division  -  Code  1112 
S">0  N.  Quincy  St. 
Arlington.  VA  2221" 

22.     Commanding  Ofl'icer 

Naval  Research  Laboraton' 
Attn:    E.  Senasack  (Code  8220) 
4555  Overbrook  Ave.. 
Washington.  DC  20375-5000 


233 


1'^1'\S>\1 


Thesis 

^m^^^M 

C1925 

Cameron       'tIB^ 

c.l 

\ 

Control  of  an  experi- 
ment to  measure  acoustic 
noise  in  the  space 
shuttle.             ^ 

] 

1 

■ 

AtS  ''O      ^  „    3  2  1  8  U  '■ 

Thesis 

C1925 

Cameron 

c.l 

Control  of  an  experi- 

ment to  measure  acoustic 

noise  in  the  space 

shuttle. 

